Not that this invalidates the results, but keep in mind if you test a whole bunch of different models against past climate records, some of them are going to match up through pure chance. The simple fact that a given model matches the past does not guarantee that it can predict the future correctly.
Aha, that Prescott v. Northwood thing sounds reasonable.
Yes both machines have the same amount of RAM (1GB), same kernel (2.4.28), same software (PRMan 12.0).
I also just got a newer system, 3.2GHz Xeon with DDR RAM. Its performance is virtually identical to the 3.06GHz Pentium 4 with RDRAM. So I guess adding ~150MHz to the clock speed makes up the processor efficiency difference.
I also highly recommend Quicktime. MPEG-1 is more widely compatible, but the MPEG-1 codec is very inefficient (at low bit rates) by today's standards. Sorenson 3 and Quicktime's MPEG-4 codec are quite efficient - not the very best, but the best ones that most PCs and Macs are likely to have installed already. I disqualify DiVX and its variants because it does not come "standard" with Windows Media Player (as Sorenson 3 and MPEG-4 come standard with Quicktime Player), there are several incompatible variants of DiVX, and it can be difficult for novices to download and install.
The only hitch with Quicktime is that you really need the ~$300 Sorenson "Pro" encoder to produce good results. The free Sorenson 3 encoder sucks.
I really hope an open-source, non-patented codec like Ogg Theora becomes popular. Web video codecs are at the point of diminshing returns with respect to efficiency - all the "MPEG-4 generation" codecs are efficient enough - the only remaining issues with them are ease of use, robustness, and cross-platform compatibility. (could we get a decent codec that works in Windows Media Player AND Quicktime Player AND an open-source player, AND whose encoder works with most video editing software?)
The DDR system is only 86% as fast as the RDRAM system (the RDRAM system is 16% faster). This is despite the DDR system having been purchased almost two years later, and having more cache!
The DDR system does pull ahead for compositing tasks (by quite a bit - in some cases it's twice as fast). I assume this is due to the larger cache.
But ray tracing takes about 90% of my total render times, so it's far more important to optimize. I am disappointed that I can't buy hardware today with the same RAM performance as I got two years ago.
I was just as mad as everyone else at Rambus' outlaw marketing tactics. But then I discovered, much to my dismay, that even the fastest currently available DDR RAM results in a ~20% speed penalty versus two-year-old RDRAM on the rendering application I use most. I would LOVE to be able to buy more RDRAM, even at a premium price.
This is a very good thing, if only because it will force developers to think in terms of arbitrary units (like "inches on the screen") as opposed to hard-coding pixel dimensions into their software*. Recent high-resolution monitors have exposed painful problems of hard-coded pixel interfaces - like text that becomes virtually unreadable at 3840x2160.
As a side benefit, this move towards a more vector-oriented display architecture means anti-aliasing will be easy to perform. Imagine dragging a window around with sub-pixel precision, and having the window contents and edges anti-aliased with a high-quality filter.
Not to knock Apple, but from what I have heard, Microsoft's implementation goes further in making the graphics API completely resolution-independent.
* and if you still want to use bitmaps for certain things, go right ahead, just let the graphics card re-size them to the appropriate pixel dimensions with high-quality filtering.
Re:PBS special next Tuesday
on
One Year on Mars
·
· Score: 2, Interesting
Those of us in the U.S. may be interested in the Welcome to Mars tht will be broadcast next Tuesday, January 4th, on Nova.
(shameless plug)
which includes about 5 minutes of new computer animation by your truly*:). The new shots of the rovers on Mars make use of actual terrain data; when you see the CG rovers they are shown in exactly the real environments down to the level of individual rocks. The lighting is also improved quite a bit over our previous work.
Tuesday at 8PM on your local PBS station. Some will follow it with a repeat of Mars, Dead or Alive, last year's pre-launch show.
* Props to assistant 3D modeler John Niehuss and software consultant Justin Wick (who happens to be a Slashdot reader too).
I was disappointed by the announcements earlier this year from Intel and AMD that they will no longer try to improve clock speeds (instead favoring multi-core CPUs, which IMHO are more difficult to optimize for).
On the other hand, perhaps this is a decoy tactic - tell everyone you aren't working on clock speed anymore, then surprise the competition later with faster clock speeds:)
I ran a very small BitTorrent tracker for distributing our videos. (2 torrents, very few clients)
A few weeks ago we started receiving a massive attack, mostly from client addresses in Asia.
The attack wasn't a DDoS per se - they were just "hijacking" my tracker by using it for their own torrents. But the volume of traffic (>100 requests/sec) had the effect of a DoS attack.
I was surprised that the standard BitTorrent server does not have some way to prevent unwanted torrents from appearing on your tracker. I was also surprised that my "small-time" tracker (only named by via 1 web page) attracted such a hijacking.
I will not run a tracker without the ability to deny usage to unwanted torrents. Although I'm uncertain about running any tracker at all now, since the hijack basically killed our internet connection.
At the very least, do not run a BitTorrent tracker on a critical DNS name like your primary web site. The attacking clients in my case were all performing DNS lookups. (I could tell they were attacking a DNS name, not an IP address, by changing my DNS entries). Luckily I had used a separate DNS entry for the tracker, so I just pointed it to 127.0.0.1 to stop the attack. But if I had used my primary web server's address, I'd be in real trouble.
Quick question - do you ever have a problem with Photoshop "forgetting" the tablet exists (and thus disabling the pressure sensitivity features)? This happens a lot on my system and is very frustrating because I have to reboot to get it back. (the tablets are otherwise just great)
I just got a 3.2GHz dual Xeon with EM64T. It runs the standard x86-64 Linux kernel just fine. Emulation of 32-bit software is excellent (the performance penalty is ~1%).
In my (64-bit) rendering benchmarks, the 3.2GHz Xeon is just a tad slower than a 2.2GHz Opteron 248.
On my benchmarks, Opteron performance benefits massively from switching to the 64-bit architecture (30-40% faster than the same software in 32-bit mode). But, on the Xeon there is virtually no difference. This leads me to believe that Intel's implementation of the 64-bit instruction set is far less optimized than AMD's. Or, perhaps GCC emits code that favors AMD's design over Intel's.
For retirement you want a SEP IRA. It's very similar to a 401k, but designed for self-employed people. The contribution limits are generous and you get the same tax benefits as a 401k. You can augment the SEP with a Roth IRA if you want.
Check health insurance rates in your locality. You could end up paying from $2,000 to over $10,000 per year for health insurance, depending on the plan. Individuals get worse rates on insurance compared to employees of a large company.
"Just recompiling" may be OK for hobbyists but is not acceptable for business. I don't want to spend time downloading the source, resolving the compile dependencies, dealing with idiotic build scripts, etc. (it is NOT easy to recompile certain common programs like the X server or Apache). I just want a binary that works.
Windows is a slave to backwards compatibility because that's what users want. They do not want to have to "upgrade" all of their applications each time a system component changes.
(for all of its failings, Windows today can successfully run most Win32 software from 1995 and before. If I grab a random ten-year-old Linux binary, will current systems run it? I wouldn't take that bet)
The first thing that disappears when you don't get paid as a developer is backwards compatibility. It's the type of thing only paying users (vs casual users and developers) care about.
I completely agree and wish the kernel API were kept more stable. Which is saying a lot, as the Linux kernel API is currently way more stable than glibc, GCC, and most user-space libraries. Virtually all of my Linux trouble-shooting time over the last few years has been caused by API versioning issues in glibc and/or GCC.
Re:I feel that the professor let his students down
on
A College Guide to EA
·
· Score: 1
Perhaps it is just too hard to find another stable and successful game company that doesn't have such an intense work schedule? EA sounds like par for the industry from what I've heard. (although an "average" game company isn't as consistently successful as EA - maybe that means something...)
Perhaps game companies exploit the strong desire of young employees to stay in the industry by working the heck out of them? i.e. it's just supply and demand?
Might be an interesting experiment for a game company to enforce a more standard business schedule... Joel Spolsky (joelonsoftware.com) did this for his software company - I think they lock the employees out after 6PM (?). Joel found you can be just as productive on a "normal" schedule because the reduced hours are compensated by increased focus and alertness. Plus you don't burn people out and raise the ire of government regulators. (Pixar does the same thing too)
I have no objection at all to a system like this. I recently returned some computer gear to Best Buy and was surprised at how generous their return policy is. I expected to pay some kind of restocking fee at least.
That said, Best Buy does stand out in my mind for treating customers more like criminals than any other store I've been to (aside from Fry's). However their anti-fraud measures don't seem to result in lower prices. I'd rather pay retail somewhere else that will treat me with at least a presumption of innocence, or better yet less than retail with no sales tax on-line.
I've seen buttons with small LED arrays for programmable labels (in e.g. aircraft instrument panels).
It's sad that all of the machine vendors seem to have just bundled up a touch-sceen Windows box and implemented the first design that came to mind rather than really thinking about how to optimize a machine for voting.
RAID stripes are typically on the order of 64KB-128KB. If you just write one filesystem block (4KB) you have to read the entire rest of the stripe to figure out the parity. But, modern drives are pretty good at large contiguous reads, so it's not that much of a big deal.
You are correct that modern CPUs kick the ass of most (probably all) RAID controllers at performing the XORs. The reason you'd want a hardware RAID system is for saving CPU cycles, cache pollution and memory/bus traffic, not for raw XOR speed. (in software RAID-5 you will see quite a bit of CPU time taken by the RAID computations, vs. virtually nothing with hardware RAID)
And yeah I'd go for as much RAM as possible in a file server.
I have a 160GB Linux software RAID-5 consisting of three 80GB disks, running 24x7 for years now. (when I built the RAID, 80GB was the largest disk capacity you could buy:).
No problems at all. I once had an IDE controller fail - I replaced it (had to reboot of course), and Linux rebuilt the array automagically.
I have not tried using a hot spare.
Warning: a lot of the documentation out there on the web about Linux software RAID is very out of date. If you go this route, DEFINITELY buy the book "Managing RAID on Linux" (O'Reilly). Also be prepared to compile the "raidtools" package, which you need to set up arrays.
I have since added an 8-disk system based on 3Ware's 9000 series SATA RAID controller. I recommend 3Ware for higher-performance systems. (I have 8 250GB disks in a single 1.6TB RAID-5, I get about 180MB/sec read, 90MB/sec write.)
You could do this with a "user-mode" filesystem that loops requests to/kio/* back out to a user-mode handler program which interprets the path. That avoids the objection about putting too much protocol stuff in the kernel. You do have to be careful about deadlocks during resource exhaustion (kernel needs to tell user-mode helper to throw away data to free memory, but user-mode helper is swapped out). I think this can be worked around however, and I bet Linus would accept a suitably safe patch to do this.
I know for sure I have seen user-mode filesystem patches floating around, but none is in the kernel right now AFAIK.
There ARE very good DVD rips of the un-altered laser discs already. Look for BitTorrents.
Also, if you look on IMDB, there were actually a few minor changes already in the early-80s re-release of ANH. They were for the better, like the "close the blast door! open the blast door!" in the chase on the Death Star.
I'm pretty sure a huge amount of the Linux driver code is shared with Windows. The part of the kernel source they provide is basically an abstraction layer; presumably they just substitute an equivalent Windows version to get the Windows driver. (of course there are differences in the X vs Win32 bindings, but I doubt that is a huge problem).
Thanks to these drivers NVIDIA has basically taken over the high-end Linux/BSD graphics card market. (nobody I know doing high-end work on Linux even considers ATI). I am sure they have sold thousands of cards for Linux use, and their Linux customers probably buy their more expensive models, since they are doing actual high-end work as opposed to playing games.
Also NVIDIA provides hardware to Apple and SGI and there is presumably some synergy between their drivers for Linux, OSX, and IRIX.
Not that this invalidates the results, but keep in mind if you test a whole bunch of different models against past climate records, some of them are going to match up through pure chance. The simple fact that a given model matches the past does not guarantee that it can predict the future correctly.
Aha, that Prescott v. Northwood thing sounds reasonable.
Yes both machines have the same amount of RAM (1GB), same kernel (2.4.28), same software (PRMan 12.0).
I also just got a newer system, 3.2GHz Xeon with DDR RAM. Its performance is virtually identical to the 3.06GHz Pentium 4 with RDRAM. So I guess adding ~150MHz to the clock speed makes up the processor efficiency difference.
I also highly recommend Quicktime. MPEG-1 is more widely compatible, but the MPEG-1 codec is very inefficient (at low bit rates) by today's standards. Sorenson 3 and Quicktime's MPEG-4 codec are quite efficient - not the very best, but the best ones that most PCs and Macs are likely to have installed already. I disqualify DiVX and its variants because it does not come "standard" with Windows Media Player (as Sorenson 3 and MPEG-4 come standard with Quicktime Player), there are several incompatible variants of DiVX, and it can be difficult for novices to download and install.
The only hitch with Quicktime is that you really need the ~$300 Sorenson "Pro" encoder to produce good results. The free Sorenson 3 encoder sucks.
I really hope an open-source, non-patented codec like Ogg Theora becomes popular. Web video codecs are at the point of diminshing returns with respect to efficiency - all the "MPEG-4 generation" codecs are efficient enough - the only remaining issues with them are ease of use, robustness, and cross-platform compatibility. (could we get a decent codec that works in Windows Media Player AND Quicktime Player AND an open-source player, AND whose encoder works with most video editing software?)
The test case was intensive ray tracing with Pixar's RenderMan on two systems:
3.06 GHz Pentium 4, 512KB cache, 533MHz FSB, RDRAM
3.00 GHz Pentium 4, 1MB cache, 800MHz FSB, DDR400 RAM
The DDR system is only 86% as fast as the RDRAM system (the RDRAM system is 16% faster). This is despite the DDR system having been purchased almost two years later, and having more cache!
The DDR system does pull ahead for compositing tasks (by quite a bit - in some cases it's twice as fast). I assume this is due to the larger cache.
But ray tracing takes about 90% of my total render times, so it's far more important to optimize. I am disappointed that I can't buy hardware today with the same RAM performance as I got two years ago.
I was just as mad as everyone else at Rambus' outlaw marketing tactics. But then I discovered, much to my dismay, that even the fastest currently available DDR RAM results in a ~20% speed penalty versus two-year-old RDRAM on the rendering application I use most. I would LOVE to be able to buy more RDRAM, even at a premium price.
This is a very good thing, if only because it will force developers to think in terms of arbitrary units (like "inches on the screen") as opposed to hard-coding pixel dimensions into their software*. Recent high-resolution monitors have exposed painful problems of hard-coded pixel interfaces - like text that becomes virtually unreadable at 3840x2160.
As a side benefit, this move towards a more vector-oriented display architecture means anti-aliasing will be easy to perform. Imagine dragging a window around with sub-pixel precision, and having the window contents and edges anti-aliased with a high-quality filter.
Not to knock Apple, but from what I have heard, Microsoft's implementation goes further in making the graphics API completely resolution-independent.
* and if you still want to use bitmaps for certain things, go right ahead, just let the graphics card re-size them to the appropriate pixel dimensions with high-quality filtering.
(shameless plug) :). The new shots of the rovers on Mars make use of actual terrain data; when you see the CG rovers they are shown in exactly the real environments down to the level of individual rocks. The lighting is also improved quite a bit over our previous work.
which includes about 5 minutes of new computer animation by your truly*
Tuesday at 8PM on your local PBS station. Some will follow it with a repeat of Mars, Dead or Alive, last year's pre-launch show.
* Props to assistant 3D modeler John Niehuss and software consultant Justin Wick (who happens to be a Slashdot reader too).
I was disappointed by the announcements earlier this year from Intel and AMD that they will no longer try to improve clock speeds (instead favoring multi-core CPUs, which IMHO are more difficult to optimize for).
:)
On the other hand, perhaps this is a decoy tactic - tell everyone you aren't working on clock speed anymore, then surprise the competition later with faster clock speeds
I ran a very small BitTorrent tracker for distributing our videos. (2 torrents, very few clients)
A few weeks ago we started receiving a massive attack, mostly from client addresses in Asia.
The attack wasn't a DDoS per se - they were just "hijacking" my tracker by using it for their own torrents. But the volume of traffic (>100 requests/sec) had the effect of a DoS attack.
I was surprised that the standard BitTorrent server does not have some way to prevent unwanted torrents from appearing on your tracker. I was also surprised that my "small-time" tracker (only named by via 1 web page) attracted such a hijacking.
I will not run a tracker without the ability to deny usage to unwanted torrents. Although I'm uncertain about running any tracker at all now, since the hijack basically killed our internet connection.
At the very least, do not run a BitTorrent tracker on a critical DNS name like your primary web site. The attacking clients in my case were all performing DNS lookups. (I could tell they were attacking a DNS name, not an IP address, by changing my DNS entries). Luckily I had used a separate DNS entry for the tracker, so I just pointed it to 127.0.0.1 to stop the attack. But if I had used my primary web server's address, I'd be in real trouble.
How did they explain supersonic rifle bullets?
Quick question - do you ever have a problem with Photoshop "forgetting" the tablet exists (and thus disabling the pressure sensitivity features)? This happens a lot on my system and is very frustrating because I have to reboot to get it back. (the tablets are otherwise just great)
I don't have any inside information, but it looks very likely that the next Final Cut release will have some kind of support for MPEG-2 HD camcorders.
I just got a 3.2GHz dual Xeon with EM64T. It runs the standard x86-64 Linux kernel just fine. Emulation of 32-bit software is excellent (the performance penalty is ~1%).
In my (64-bit) rendering benchmarks, the 3.2GHz Xeon is just a tad slower than a 2.2GHz Opteron 248.
On my benchmarks, Opteron performance benefits massively from switching to the 64-bit architecture (30-40% faster than the same software in 32-bit mode). But, on the Xeon there is virtually no difference. This leads me to believe that Intel's implementation of the 64-bit instruction set is far less optimized than AMD's. Or, perhaps GCC emits code that favors AMD's design over Intel's.
For retirement you want a SEP IRA. It's very similar to a 401k, but designed for self-employed people. The contribution limits are generous and you get the same tax benefits as a 401k. You can augment the SEP with a Roth IRA if you want.
Check health insurance rates in your locality. You could end up paying from $2,000 to over $10,000 per year for health insurance, depending on the plan. Individuals get worse rates on insurance compared to employees of a large company.
"Just recompiling" may be OK for hobbyists but is not acceptable for business. I don't want to spend time downloading the source, resolving the compile dependencies, dealing with idiotic build scripts, etc. (it is NOT easy to recompile certain common programs like the X server or Apache). I just want a binary that works.
Windows is a slave to backwards compatibility because that's what users want. They do not want to have to "upgrade" all of their applications each time a system component changes.
(for all of its failings, Windows today can successfully run most Win32 software from 1995 and before. If I grab a random ten-year-old Linux binary, will current systems run it? I wouldn't take that bet)
The first thing that disappears when you don't get paid as a developer is backwards compatibility. It's the type of thing only paying users (vs casual users and developers) care about.
I completely agree and wish the kernel API were kept more stable. Which is saying a lot, as the Linux kernel API is currently way more stable than glibc, GCC, and most user-space libraries. Virtually all of my Linux trouble-shooting time over the last few years has been caused by API versioning issues in glibc and/or GCC.
Perhaps it is just too hard to find another stable and successful game company that doesn't have such an intense work schedule? EA sounds like par for the industry from what I've heard. (although an "average" game company isn't as consistently successful as EA - maybe that means something...)
Perhaps game companies exploit the strong desire of young employees to stay in the industry by working the heck out of them? i.e. it's just supply and demand?
Might be an interesting experiment for a game company to enforce a more standard business schedule... Joel Spolsky (joelonsoftware.com) did this for his software company - I think they lock the employees out after 6PM (?). Joel found you can be just as productive on a "normal" schedule because the reduced hours are compensated by increased focus and alertness. Plus you don't burn people out and raise the ire of government regulators. (Pixar does the same thing too)
I have no objection at all to a system like this. I recently returned some computer gear to Best Buy and was surprised at how generous their return policy is. I expected to pay some kind of restocking fee at least.
That said, Best Buy does stand out in my mind for treating customers more like criminals than any other store I've been to (aside from Fry's). However their anti-fraud measures don't seem to result in lower prices. I'd rather pay retail somewhere else that will treat me with at least a presumption of innocence, or better yet less than retail with no sales tax on-line.
I've seen buttons with small LED arrays for programmable labels (in e.g. aircraft instrument panels).
It's sad that all of the machine vendors seem to have just bundled up a touch-sceen Windows box and implemented the first design that came to mind rather than really thinking about how to optimize a machine for voting.
RAID stripes are typically on the order of 64KB-128KB. If you just write one filesystem block (4KB) you have to read the entire rest of the stripe to figure out the parity. But, modern drives are pretty good at large contiguous reads, so it's not that much of a big deal.
You are correct that modern CPUs kick the ass of most (probably all) RAID controllers at performing the XORs. The reason you'd want a hardware RAID system is for saving CPU cycles, cache pollution and memory/bus traffic, not for raw XOR speed. (in software RAID-5 you will see quite a bit of CPU time taken by the RAID computations, vs. virtually nothing with hardware RAID)
And yeah I'd go for as much RAM as possible in a file server.
I have a 160GB Linux software RAID-5 consisting of three 80GB disks, running 24x7 for years now. (when I built the RAID, 80GB was the largest disk capacity you could buy :).
No problems at all. I once had an IDE controller fail - I replaced it (had to reboot of course), and Linux rebuilt the array automagically.
I have not tried using a hot spare.
Warning: a lot of the documentation out there on the web about Linux software RAID is very out of date. If you go this route, DEFINITELY buy the book "Managing RAID on Linux" (O'Reilly). Also be prepared to compile the "raidtools" package, which you need to set up arrays.
I have since added an 8-disk system based on 3Ware's 9000 series SATA RAID controller. I recommend 3Ware for higher-performance systems. (I have 8 250GB disks in a single 1.6TB RAID-5, I get about 180MB/sec read, 90MB/sec write.)
You could do this with a "user-mode" filesystem that loops requests to /kio/* back out to a user-mode handler program which interprets the path. That avoids the objection about putting too much protocol stuff in the kernel. You do have to be careful about deadlocks during resource exhaustion (kernel needs to tell user-mode helper to throw away data to free memory, but user-mode helper is swapped out). I think this can be worked around however, and I bet Linus would accept a suitably safe patch to do this.
I know for sure I have seen user-mode filesystem patches floating around, but none is in the kernel right now AFAIK.
For releases, yes. But for shortening the compile/run/debug cycle a faster compiler would be great.
There ARE very good DVD rips of the un-altered laser discs already. Look for BitTorrents.
Also, if you look on IMDB, there were actually a few minor changes already in the early-80s re-release of ANH. They were for the better, like the "close the blast door! open the blast door!" in the chase on the Death Star.
I'm pretty sure a huge amount of the Linux driver code is shared with Windows. The part of the kernel source they provide is basically an abstraction layer; presumably they just substitute an equivalent Windows version to get the Windows driver. (of course there are differences in the X vs Win32 bindings, but I doubt that is a huge problem).
Thanks to these drivers NVIDIA has basically taken over the high-end Linux/BSD graphics card market. (nobody I know doing high-end work on Linux even considers ATI). I am sure they have sold thousands of cards for Linux use, and their Linux customers probably buy their more expensive models, since they are doing actual high-end work as opposed to playing games.
Also NVIDIA provides hardware to Apple and SGI and there is presumably some synergy between their drivers for Linux, OSX, and IRIX.