Have you thought about putting your changes under some sort of version control software? If you started putting the kernel/patches under CVS, maybe the rest of the kernel crowd would follow.
I don't know about specific implementations of the pthreads API, but there is little reason why the most calls can't be done purely in user space. All the threads are already in the same process, so shared memory isn't an issue. Processor instructions such as "test and set" don't typically need supervisor priveleges.
Of course, I'm overgeneralizing again and someone will jump on me for that:)
The Linux interfaces show the traditional SVR5 semaphores to be the slowest performers while the pthread mutexes are the fastest.
well duh. Just look at the section of the man pages -- semop is in section 2 (system calls) and pthreads are in section 3 (library calls). As a general rule of thumb, system calls will be slower than library calls (a context switch is involved).
To try my hand at making maps, I built an Action Quake map of my condo/townhouse building. Only problem is whenever I enter the living room now I duck for cover behind the sofa.
I don't think they've been in production for a long time. Go punch in "intel 4004" at ebay.
Re:Street Dating Explained From the Inside
on
Gamecube Hits US Early
·
· Score: 3, Interesting
From my experience at a music/video store, product usually gets to the store ~1 week before release. If a distributor finds you stocking your shelves with it early they'll often "punish" you by not sending the merchandise early next time, perhaps waiting until the release date or slightly after to send you the new merchandise.
. . . if you buy the compiler, you are allowed to distribute code that you compile with icc;)
I realize you've got a smiley there, but I've got to say: Duh! Who would use/buy a compiler that didn't allow you to distribute your binaries? That would be like using a word processor where you didn't own the work you wrote.
Though it wouldn't surprise me if sooner or later the Microsoft C++ or Word license would claim that any work produced with the tools is property of MS.
I wasn't really expecting C++ compatibility, name mangling is typically compiler specific. C compatibility shouldn't be terribly difficult to maintain. Of course, it either works or it doesn't.
I wonder if Intel's compiler is binary compatible with gcc. While it's probably against the licensing to redistribute the compiler's math or C library, I wonder if you could compile the gnu math/C library with icc and produce a shared object? An optimized math or other system library would give some decent improvement in performance.
Re:problem with large storage mp3 players
on
80 Gig MP3 Player
·
· Score: 1
My algorithms are getting actually pretty complex for doing this and I want to keep them to myself somewhat for now. But that is the general way that things work.
yeah they're complex! My previous job was at Cantametrix, one of the things we did was a similarity model for music. This involved extracting attributes from music (tempo, melody, and tons of low-level stuff), throw that in a database, and run a similarity model on it. The best part was it was completely automated, humans never had to hear the songs. It worked decently, but the company eventually switched focus to doing song fingerprinting (which wasn't as big of an about face as you'd think). Something like that would be great for a jukebox.
anyway, we could take this to email if you'd like. Seems this subject isn't drawing many more posters.
Re:problem with large storage mp3 players
on
80 Gig MP3 Player
·
· Score: 1
And you won't ever hear "Rage Against The Machine" followed by "I Shot The Sheriff". It is smart enough to avoid songs that are that dissimilar.
nice. How did you accomplish this? I've got my ideas [ie- basic graph algorithm stuff], but it's always nice to see what someone else did.
as is typical, the mechanism was broken not because of the crypto algorithm but because of the implementation.
Re:problem with large storage mp3 players
on
80 Gig MP3 Player
·
· Score: 2
I've encountered the "navigation" problem with my ~6000 song mp3 collection. I was going to use something like grip/digital DJ but I'm more interested in rolling my own solution (no offense Mike, your tools are good). I think it's the geek in me looking for a project. So far I've got a SQL database and the beginnings of some perl for ripping/storing CDs/metadata. I had the benefit of scripting ripping software at a previous job where we ripped 1,000 CDs and enconded via various mp3 encoders and vorbis, so I've got a good foundation to build on.
In the end, I'm shooting to hook up my Vaio laptop to the home stereo. Combine that with NFS over an 802.11b wireless network and the digital optical output (skip the laptop's inferior soundcard) and it should be a pretty decent system.
Oh, navigation. That's what I meant to be talking about...besides having verbose filenames/directories, allowing the if you provide the database with 2 or more genres (or genre/subgenre) navigation isn't terribly difficult. Plus if you represent genres as some sort of adjency matrix you could implement a random play mode that wouldn't jump genres too harshely.
I've been thinking about getting a 802.11b network going on my lan, and thinking about how to make it somewhat secure.
My idea is to add a third NIC to my firewall/masq/server machine, which the wireless hub hanging exclusively off this NIC. That way I could add some ipchains rules that only apply to the wireless network.
The question is, what sort of ipchains rules? One idea I had was to only allow the MAC address of known/authorized cards (this would require iptables/kernel 2.4 -- ipchains doesn't look at MAC AFAIK). Even though MAC address could be spoofed, it would probably be enough for my home lan.
Is this similar to what other people have tried? What do other people do for this?
I doubt any Slashdotters know C.W. McCall. We had the 7" of Convoy in our high school cafeteria jukebox. The song was so cheezy and dukes of hazzard wannabe it was just funny. Then the awful female backing vocals come in...
The ChangeLog definitely needs some verbosity. The word to the wise is "only update if you need to", yet viewing the changelog leaves one wondering if they need the newer software.
What exactly do entries like "shrink dcache/icache more aggressively" or "random bugfix" mean? The former I'd guess has to do with data and instruction caches, but what aggressively shrinking does to them I have no clue without a more context. And the latter, "random bugfix", I hit my coworkers over the head when I see that in our CVS logs.
So is my current kernel effected? Am I missing out by not having my dcache/icache shrunk more aggressively? Or maybe those random bufixes effect me? A little more verbosity in the ChangeLog would go a long way. Having to follow the hacker's mailing list is not an option, this should be included in the release notes.
Anyone have a list of ipchains rules / ports that need to be forwarded to play RTCW from a IP masqueraded / firewalled lan? I've got a linux box running ipchains / masquerading and can't seem to get RTCW going with ipchains up.
I know RTCW uses udp ports in the 27950-60 range, but simply port forwarding these across the lan doesn't seems to work. I didn't have to do anything fancy to get Unreal Tournament working, so I'm wondering if RTCW did something wierd with their networking code.
I don't know about other shells, but tcsh has some features that provide other useless statistics. You can set a variable called "time" that can provide additional information. From the tcsh man page [edited]:
time: If set to a number, then the time builtin (q.v.) executes automatically after each command which takes more than that many CPU seconds. If there is a second word, it is used as a format string for the output of the time builtin. (u) The following sequences may be used in the format string:
%U The time the process spent in user mode in cpu seconds.
%S The time the process spent in kernel mode in cpu seconds.
%E The elapsed (wall clock) time in seconds.
%P The CPU percentage computed as (%U + %S) / %E.
%W Number of times the process was swapped.
%X The average amount in (shared) text space used in Kbytes.
%D The average amount in (unshared) data/stack space used in Kbytes.
%K The total space used (%X + %D) in Kbytes.
%M The maximum memory the process had in use at any time in Kbytes.
%F The number of major page faults (page needed to be brought from disk).
%R The number of minor page faults.
Particularly, if you could measure the number of swaps/page faults in
the different kernels it would be pretty useful. I've got $time set
to:
# have time report verbose useless statistics
set time= ( 30 "%Uuser %Skernel %Eelapsed %Wswap %Xtxt %Ddata %Ktotal %Mmax %Fmajpf %Rminpf %I+%Oio" )
comparing the old and new benchmarks would give a good indication on how much Arcangeli's VM improves things.
it actually won't give a good indication, see my post elsewhere in this article. Basically, in addition to the newer kernel, the author is also throwing in newer versions of mysql, sendmail, apache etc etc and recompiling everything with a newer version of gcc.
and what he going to say after he finds an improvement of X%? The new linux VM rocks? Exactly how much of this was due to the new VM? After taking gcc, mysql and everything else into account...who knows. So if the author is doing the test he described, it's not a benchmark of the old VM versus the new.
Upon returning home the other week after meeting with Andrea, I went to my lab and searched for the disk images of the server comparison I ran back in January of this year (of FreeBSD 4.1.1 versus Linux 2.4.0). I took the Compaq ML500 server I have been reviewing (2x 1-GHz CPUs, 2-GB RAM) and upgraded both the FreeBSD disk image to 4.4-Stable and the Linux version to 2.4.12.
Good, this would be an interesting benchmark.
Then, I changed the memory down to 192-MB RAM so as to stress the VM system more.
ok, this is fair, but you should also run with the same memory configuration you originally ran.
I also upgraded to the latest stable versions of Sendmail (8.12.1) and MySQL (version 3.23.42). Finally, I compiled everything with the latest version of gcc, 3.0.2, and tuned the two instances to the best of my knowledge (softupdates and increased maxusers for FreeBSD, and untouched default values for Linux).
NO!!!! why would you do this? Don't you want to know how the earlier linux/FreeBSD kernel compares to a later ones? Now instead of modifying one variable you've modified 3,846 variables. It's going to see if any improvements in FreeBSD/Linux are due to an updated kernel, compiler, mysql, etc etc. Go back to your original setup and only change the kernel, since I believe that's what you want to benchmark.
The java jockeys kept pushing for the client / server to talk XML. After pointing out that the majority of their protocal was XML overhead (never mind that it was *neatly* *formatted* XML [the perl CGI stuff produces ugly looking html for a reason: newlines take up bandwidth!]) they claimed it was only the "1.0" implementation. Huh??? Solidifying a protocol should be high priority, unless you're happy pissing off your customers with constantly changing specs.
Slashdot Mirror
Have you thought about putting your changes under some sort of version control software? If you started putting the kernel/patches under CVS, maybe the rest of the kernel crowd would follow.
I bet they could add an option to *just* view the R portion of the movie. Skip that boring stuff, bring me the violence and gratuitous sex!
I don't know about specific implementations of the pthreads API, but there is little reason why the most calls can't be done purely in user space. All the threads are already in the same process, so shared memory isn't an issue. Processor instructions such as "test and set" don't typically need supervisor priveleges.
:)
Of course, I'm overgeneralizing again and someone will jump on me for that
The Linux interfaces show the traditional SVR5 semaphores to be the slowest performers while the pthread mutexes are the fastest.
well duh. Just look at the section of the man pages -- semop is in section 2 (system calls) and pthreads are in section 3 (library calls). As a general rule of thumb, system calls will be slower than library calls (a context switch is involved).
To try my hand at making maps, I built an Action Quake map of my condo/townhouse building. Only problem is whenever I enter the living room now I duck for cover behind the sofa.
I don't think they've been in production for a long time. Go punch in "intel 4004" at ebay.
From my experience at a music/video store, product usually gets to the store ~1 week before release. If a distributor finds you stocking your shelves with it early they'll often "punish" you by not sending the merchandise early next time, perhaps waiting until the release date or slightly after to send you the new merchandise.
Unless the "Anonymous Coward" was replaced by "Kiro" in the new Slashcode, you better hope they don't sue or fire.
I wouldn't worry about it. Really.
I realize you've got a smiley there, but I've got to say: Duh! Who would use/buy a compiler that didn't allow you to distribute your binaries? That would be like using a word processor where you didn't own the work you wrote.
Though it wouldn't surprise me if sooner or later the Microsoft C++ or Word license would claim that any work produced with the tools is property of MS.
I wasn't really expecting C++ compatibility, name mangling is typically compiler specific. C compatibility shouldn't be terribly difficult to maintain. Of course, it either works or it doesn't.
I wonder if Intel's compiler is binary compatible with gcc. While it's probably against the licensing to redistribute the compiler's math or C library, I wonder if you could compile the gnu math/C library with icc and produce a shared object? An optimized math or other system library would give some decent improvement in performance.
yeah they're complex! My previous job was at Cantametrix, one of the things we did was a similarity model for music. This involved extracting attributes from music (tempo, melody, and tons of low-level stuff), throw that in a database, and run a similarity model on it. The best part was it was completely automated, humans never had to hear the songs. It worked decently, but the company eventually switched focus to doing song fingerprinting (which wasn't as big of an about face as you'd think). Something like that would be great for a jukebox. anyway, we could take this to email if you'd like. Seems this subject isn't drawing many more posters.
nice. How did you accomplish this? I've got my ideas [ie- basic graph algorithm stuff], but it's always nice to see what someone else did.
as is typical, the mechanism was broken not because of the crypto algorithm but because of the implementation.
I've encountered the "navigation" problem with my ~6000 song mp3 collection. I was going to use something like grip/digital DJ but I'm more interested in rolling my own solution (no offense Mike, your tools are good). I think it's the geek in me looking for a project. So far I've got a SQL database and the beginnings of some perl for ripping/storing CDs/metadata. I had the benefit of scripting ripping software at a previous job where we ripped 1,000 CDs and enconded via various mp3 encoders and vorbis, so I've got a good foundation to build on.
In the end, I'm shooting to hook up my Vaio laptop to the home stereo. Combine that with NFS over an 802.11b wireless network and the digital optical output (skip the laptop's inferior soundcard) and it should be a pretty decent system.
Oh, navigation. That's what I meant to be talking about...besides having verbose filenames/directories, allowing the if you provide the database with 2 or more genres (or genre/subgenre) navigation isn't terribly difficult. Plus if you represent genres as some sort of adjency matrix you could implement a random play mode that wouldn't jump genres too harshely.
I've been thinking about getting a 802.11b network going on my lan, and thinking about how to make it somewhat secure.
My idea is to add a third NIC to my firewall/masq/server machine, which the wireless hub hanging exclusively off this NIC. That way I could add some ipchains rules that only apply to the wireless network.
The question is, what sort of ipchains rules? One idea I had was to only allow the MAC address of known/authorized cards (this would require iptables/kernel 2.4 -- ipchains doesn't look at MAC AFAIK). Even though MAC address could be spoofed, it would probably be enough for my home lan.
Is this similar to what other people have tried? What do other people do for this?
Let them truckers roll, 10-4!
The ChangeLog definitely needs some verbosity. The word to the wise is "only update if you need to", yet viewing the changelog leaves one wondering if they need the newer software.
What exactly do entries like "shrink dcache/icache more aggressively" or "random bugfix" mean? The former I'd guess has to do with data and instruction caches, but what aggressively shrinking does to them I have no clue without a more context. And the latter, "random bugfix", I hit my coworkers over the head when I see that in our CVS logs.
So is my current kernel effected? Am I missing out by not having my dcache/icache shrunk more aggressively? Or maybe those random bufixes effect me? A little more verbosity in the ChangeLog would go a long way. Having to follow the hacker's mailing list is not an option, this should be included in the release notes.
Anyone have a list of ipchains rules / ports that need to be forwarded to play RTCW from a IP masqueraded / firewalled lan? I've got a linux box running ipchains / masquerading and can't seem to get RTCW going with ipchains up.
I know RTCW uses udp ports in the 27950-60 range, but simply port forwarding these across the lan doesn't seems to work. I didn't have to do anything fancy to get Unreal Tournament working, so I'm wondering if RTCW did something wierd with their networking code.
I don't know about other shells, but tcsh has some features that provide other useless statistics. You can set a variable called "time" that can provide additional information. From the tcsh man page [edited]:
time: If set to a number, then the time builtin (q.v.) executes automatically after each command which takes more than that many CPU seconds. If there is a second word, it is used as a format string for the output of the time builtin. (u) The following sequences may be used in the format string:
%U The time the process spent in user mode in cpu seconds.
%S The time the process spent in kernel mode in cpu seconds.
%E The elapsed (wall clock) time in seconds.
%P The CPU percentage computed as (%U + %S) / %E.
%W Number of times the process was swapped.
%X The average amount in (shared) text space used in Kbytes.
%D The average amount in (unshared) data/stack space used in Kbytes.
%K The total space used (%X + %D) in Kbytes.
%M The maximum memory the process had in use at any time in Kbytes.
%F The number of major page faults (page needed to be brought from disk).
%R The number of minor page faults.
Particularly, if you could measure the number of swaps/page faults in
the different kernels it would be pretty useful. I've got $time set
to:
# have time report verbose useless statistics
set time= ( 30 "%Uuser %Skernel %Eelapsed %Wswap %Xtxt %Ddata %Ktotal %Mmax %Fmajpf %Rminpf %I+%Oio" )
isn't civ so much better with a blue neon light case?
it actually won't give a good indication, see my post elsewhere in this article. Basically, in addition to the newer kernel, the author is also throwing in newer versions of mysql, sendmail, apache etc etc and recompiling everything with a newer version of gcc.
and what he going to say after he finds an improvement of X%? The new linux VM rocks? Exactly how much of this was due to the new VM? After taking gcc, mysql and everything else into account...who knows. So if the author is doing the test he described, it's not a benchmark of the old VM versus the new.
Good, this would be an interesting benchmark.
Then, I changed the memory down to 192-MB RAM so as to stress the VM system more.
ok, this is fair, but you should also run with the same memory configuration you originally ran.
I also upgraded to the latest stable versions of Sendmail (8.12.1) and MySQL (version 3.23.42). Finally, I compiled everything with the latest version of gcc, 3.0.2, and tuned the two instances to the best of my knowledge (softupdates and increased maxusers for FreeBSD, and untouched default values for Linux).
NO!!!! why would you do this? Don't you want to know how the earlier linux/FreeBSD kernel compares to a later ones? Now instead of modifying one variable you've modified 3,846 variables. It's going to see if any improvements in FreeBSD/Linux are due to an updated kernel, compiler, mysql, etc etc. Go back to your original setup and only change the kernel, since I believe that's what you want to benchmark.
this page lists the half life of cesium isotopes. Apparently they need a new entry for the half life of Cesium OS when slashdotted...
you must of worked at my previous job!
The java jockeys kept pushing for the client / server to talk XML. After pointing out that the majority of their protocal was XML overhead (never mind that it was *neatly* *formatted* XML [the perl CGI stuff produces ugly looking html for a reason: newlines take up bandwidth!]) they claimed it was only the "1.0" implementation. Huh??? Solidifying a protocol should be high priority, unless you're happy pissing off your customers with constantly changing specs.