I don't get it. Linux is close enough to Irix to make portability a cinch (compared to Win32), and aside from the endianness issue of your data, there should be no issues at all in moving to a Linux platform. It's not as if the Unix world hasn't known "SGI is dying" for almost half a decade now. Kick your vendors in the ass for a Linux version. Dumb ass vendors...:-)
One benefit of Solaris on x86-64 is again, aside from the endian problem, relatively easy portability...
There's two things you can do... dedicate more and more transistors to gaining instruction-level-parallelism, or just simplify the chips, increase clockspeed, and put more cores on a single die.
The whole SMT fiasco has been about trying to gain benefits from a stalled processor pipeline by reexecuting alternate threads...
Which is a big reason why AMD doesn't have this feature on their roadmap. Dual core is where it's at. Hyperthreading was Intel's solution to a poor design decision (a 20stage pipeline).
The point of CMT/SMT is to take stalled transistors, waiting on L1/L2/L3 main memory data, and put them to good use on other queued tasks. So CPU1 has something like this in it's pipeline
thread1-IP: value thread2-IP: value
thread1 gets dispatched, executes in multiple parallel pipelines, gets caught waiting for data. CPU takes extra pipeline, throws away results executes thread2.
If thread2 stalls, returns to thread1. If thread1 results turn out bad (the discarded pipeline results were the right one), complete thread2, reissue thread1.
This is why SMT/hyperthreading gives you only incremental benefit, and can actually cost you performance.
You can get a benefit by truly parallelizing the ENTIRE execution pipeline. Multiple pipelines, multiple execution units. But that's just dual core, so stop making complex CPU's, and start putting 20 of them on a die and bam. Supercomputing on a chip.
Forking has been made very efficient in modern unixes, and has very few of the multiprocessing issues that threading does. It's the main reason why Postgres still is not multithreaded on Linux: there's no benefit, and only pain and suffering.
Thread implementations really need protected memory. In order for thread A to access memory owned by thread B, it must be granted permission, or have a handle to said memory. Problem is, that kind of brings you back to the fork() implementation. Why not just use that instead?
Threads get you performance, but at a cost. Thread synchronization can kill all your performance gains. It's why Apache didn't have a threaded MPM until recently, and why it's still not the default (process stability, security, etc).
The only thing intel's hyperthreading buys you, and what most symmetric multithreading implementations buy you, is a solution to the cache miss problem. If your pipeline stalls, you simply execute the next thread in the list until you get the data you need.
Now, in some sophisticated designs, which is what I'd expected the P4 to do, was to turn the extra parallel execution units into independant ones, so you could issue 2 or 3 instructions simultaneously, and forgoe all the branch prediction, etc.
Turns out that the P4 20 stage pipeline needed help. SMT/Hyperthreading was it.
For some years, WindowsNT was THE defacto threading king. Efficient, easy to use, well defined semantics. Compared to the hell that was Posix Pthreads in 1994-1997... Condition variables were the only thing pthreads added that Windows didn't have, but those are damned easy to emulate (It's just a matter of how expensive it is).
The biggest problem with thread synchronization is mixed primitives. On windows, for instance, a thread can take ownership of a mutex several times, IE it can never block on a mutex that it already owns. Some primitives aren't so forgiving, and that can prove to be a nasty little problem.
It is one very tough nut to crack. The ACE toolkit <url:www.cs.wustl.edu/~schmidt> has a number of Reactor patterns in it that have simplified my developement, doing what you've marked above, helping keep synchronization to a minimum. One of the best solutions however to deadlock is to use the try_lock() and abort. Most modern unixes and Windows support this feature. A deadlock should never occur, in reality.
A) It was designed as a graphics workstation in a day and age when something like the Radeon X800 was but a dream and a Voodoo cost $2500. B) Weighed 75 pounds, had motorized doors, and SCSI drive arrays stored NASCAR grade roll cages.
Yeah, but his business has the opportunity to snowball [or fail], he'd probably still be stacking shelves, mopping up puke and urine from whiny kids in a year otherwise...
I can say the same thing about the mess of perl I have to maintain, and the bloat of 10 - 15 year old C++ code that I've had to debug and patch. Every language has it's idiots and it's experts. My VBA would make you cry in happiness over it's maintainability and cleanliness. It's all in the practicioner.
But it does have some serious limitations that make me not like it, particularly it's uselessness on any platform except Windows. 90% of the fun stuff you can do with VBA is with COM objects.
How ironic do you think it is that this will eventually be true? From MFC/ATL to DAO/RDO/ADO and the IDX/HDC fiasco to ASP and ASP.NET?
I'm sick of finishing a project, only to have the next one require interfacing with the newest damn MS product using a new interface/language..NET is continuing proof that Microsoft cannot act like a grownup and work with the rest of the industry by writing a verison of VB for the Sun JVM. Rather than cooperate to build the ultimate computing environment, they have NIH syndrome and fragment the industry.
I learn C# only to make myself worth something, but from now on, every project I write for personal usage or work on for OSS will either use C++, Perl or Java.
I just finished a contract with a trading firm to build a year-end customer reporting tool in Access. Needless to say, 48 hours later, after having the version changed from Office 2000 to OfficeXP 45 hours into the project, and having the DateTimePicker control removed, I will *NEVER* write another embedded VBA project again (except maybe Outlook. Outlook VBA has rarely broken my projects.)
There were enough bugs and differences between versions that my code broke. Personally, I'd rather have written the app in VB and used Access via MDAC/ADO. Never again, and that goes for Excel and Word too... <shudder>
VBA is actually a pretty formiddable scripting language. Nowhere near as powerful as perl, but quick, dirty and relatively clean.
Please note that I qualified that statement with further statements. It definitely occurred for me in services running as LocalSystem on an English base OS with Japanese installed. Trying to convert from iso-2022-jp to sjis or euc-jp was a PITA in that environment, even if the same code worked in my testbed.
For many reasons that I won't explain here, the service HAD to run as localsystem. Stupid fscking developers...:-/
The biggest concept of microkernels that I like is kernel driver isolation. There are kernels out there that let you put untrusted or misbehaving drivers into user space. This, *I* think, is one of the greatest failings of going with a monolithic kernel. Such a mechanism would in theory allow 32bit and 64bit drivers to coexist.
I love open source, but I'm not as rabid about non-binary drivers as some in the OSS movement are. Oh well. Just remember, when the HURD has critical mass, the real guts of the OSS movement (KDE, Xorg, Gnome, Evolution, Mozilla) will already be in place. Linux is just a kernel. In time, it too may see it's sunset for something better. In a way, the Hurd has it even better than Linux since a lot of the driver problems have already been solved.
I disagree. I think if they can pump out Mac Minis and can avoid the production problems that plagued the iMac, I think they can make serious inroads. The real test will be when we start seeing serious advertising begin, which leads me to think that A) they learned their lesson from the iMac debacle, and B) they haven't figured out production yet.
But it's still broken. Certain Japanese conversion functions do not work properly if you have an English version of Windows installed with Japanese Language packs installed as well. Not even setting the default locale will correct the problem. Actually, I believe it stems from the fact (or so it appears) that you cannot alter the system locale if you need to run services as NT_LOCAL_AUTHORITY\System.
Windows is fabulous. I've been a fan since 3.11 and NT 3.1 (going on 11 years now), but I've been a Unix fan just as long, and if we as a community can just get over the fact that Windows brings great technologies to the user, and our goal is to help move Linux forward through technical excellence rather than rabid evangelism.
No, patents still have to stand on their own and are ultimately either settled or decided by a judge. Freely giving patents to the OSS movement doesn't affect this. It just gives us patents to defend our work with.
Slashdot Mirror
I don't get it. Linux is close enough to Irix to make portability a cinch (compared to Win32), and aside from the endianness issue of your data, there should be no issues at all in moving to a Linux platform. It's not as if the Unix world hasn't known "SGI is dying" for almost half a decade now. Kick your vendors in the ass for a Linux version. Dumb ass vendors... :-)
One benefit of Solaris on x86-64 is again, aside from the endian problem, relatively easy portability...
There's two things you can do... dedicate more and more transistors to gaining instruction-level-parallelism, or just simplify the chips, increase clockspeed, and put more cores on a single die.
The whole SMT fiasco has been about trying to gain benefits from a stalled processor pipeline by reexecuting alternate threads...
Which is a big reason why AMD doesn't have this feature on their roadmap. Dual core is where it's at. Hyperthreading was Intel's solution to a poor design decision (a 20stage pipeline).
The point of CMT/SMT is to take stalled transistors, waiting on L1/L2/L3 main memory data, and put them to good use on other queued tasks. So CPU1 has something like this in it's pipeline
thread1-IP: value
thread2-IP: value
thread1 gets dispatched, executes in multiple parallel pipelines, gets caught waiting for data.
CPU takes extra pipeline, throws away results executes thread2.
If thread2 stalls, returns to thread1. If thread1 results turn out bad (the discarded pipeline results were the right one), complete thread2, reissue thread1.
This is why SMT/hyperthreading gives you only incremental benefit, and can actually cost you performance.
You can get a benefit by truly parallelizing the ENTIRE execution pipeline. Multiple pipelines, multiple execution units. But that's just dual core, so stop making complex CPU's, and start putting 20 of them on a die and bam. Supercomputing on a chip.
Forking has been made very efficient in modern unixes, and has very few of the multiprocessing issues that threading does. It's the main reason why Postgres still is not multithreaded on Linux: there's no benefit, and only pain and suffering.
Thread implementations really need protected memory. In order for thread A to access memory owned by thread B, it must be granted permission, or have a handle to said memory. Problem is, that kind of brings you back to the fork() implementation. Why not just use that instead?
Threads get you performance, but at a cost. Thread synchronization can kill all your performance gains. It's why Apache didn't have a threaded MPM until recently, and why it's still not the default (process stability, security, etc).
The only thing intel's hyperthreading buys you, and what most symmetric multithreading implementations buy you, is a solution to the cache miss problem. If your pipeline stalls, you simply execute the next thread in the list until you get the data you need.
Now, in some sophisticated designs, which is what I'd expected the P4 to do, was to turn the extra parallel execution units into independant ones, so you could issue 2 or 3 instructions simultaneously, and forgoe all the branch prediction, etc.
Turns out that the P4 20 stage pipeline needed help. SMT/Hyperthreading was it.
For some years, WindowsNT was THE defacto threading king. Efficient, easy to use, well defined semantics. Compared to the hell that was Posix Pthreads in 1994-1997... Condition variables were the only thing pthreads added that Windows didn't have, but those are damned easy to emulate (It's just a matter of how expensive it is).
The biggest problem with thread synchronization is mixed primitives. On windows, for instance, a thread can take ownership of a mutex several times, IE it can never block on a mutex that it already owns. Some primitives aren't so forgiving, and that can prove to be a nasty little problem.
It is one very tough nut to crack. The ACE toolkit <url:www.cs.wustl.edu/~schmidt> has a number of Reactor patterns in it that have simplified my developement, doing what you've marked above, helping keep synchronization to a minimum. One of the best solutions however to deadlock is to use the try_lock() and abort. Most modern unixes and Windows support this feature. A deadlock should never occur, in reality.
No sniper worth his salt his going to use a laser because:
A) lasers do not take into account windage and bullet trajectory, and
B) They give the sniper away.
Lasers to guide bombs, yeah, that's one thing... not bullets.
So she killed herself, then?
Panda was expensive because:
A) It was designed as a graphics workstation in a day and age when something like the Radeon X800 was but a dream and a Voodoo cost $2500.
B) Weighed 75 pounds, had motorized doors, and SCSI drive arrays stored NASCAR grade roll cages.
That's why Panda died.
Yeah, but his business has the opportunity to snowball [or fail], he'd probably still be stacking shelves, mopping up puke and urine from whiny kids in a year otherwise...
I can say the same thing about the mess of perl I have to maintain, and the bloat of 10 - 15 year old C++ code that I've had to debug and patch. Every language has it's idiots and it's experts. My VBA would make you cry in happiness over it's maintainability and cleanliness. It's all in the practicioner.
But it does have some serious limitations that make me not like it, particularly it's uselessness on any platform except Windows. 90% of the fun stuff you can do with VBA is with COM objects.
Anywho, my regards.
-Chris
You'd be surprised the number of applications being built by small and medium sized business around the Microsoft Office "Platform". It's disgusting.
How ironic do you think it is that this will eventually be true? From MFC/ATL to DAO/RDO/ADO and the IDX/HDC fiasco to ASP and ASP.NET?
.NET is continuing proof that Microsoft cannot act like a grownup and work with the rest of the industry by writing a verison of VB for the Sun JVM. Rather than cooperate to build the ultimate computing environment, they have NIH syndrome and fragment the industry.
I'm sick of finishing a project, only to have the next one require interfacing with the newest damn MS product using a new interface/language.
I learn C# only to make myself worth something, but from now on, every project I write for personal usage or work on for OSS will either use C++, Perl or Java.
Damn Microsoft.
In an office environment, I'd put it neck and neck with Evolution, with a good edge to OOo.
I just finished a contract with a trading firm to build a year-end customer reporting tool in Access. Needless to say, 48 hours later, after having the version changed from Office 2000 to OfficeXP 45 hours into the project, and having the DateTimePicker control removed, I will *NEVER* write another embedded VBA project again (except maybe Outlook. Outlook VBA has rarely broken my projects.)
There were enough bugs and differences between versions that my code broke. Personally, I'd rather have written the app in VB and used Access via MDAC/ADO. Never again, and that goes for Excel and Word too... <shudder>
VBA is actually a pretty formiddable scripting language. Nowhere near as powerful as perl, but quick, dirty and relatively clean.
<dons asbestos underwear>
Flame on.
Please note that I qualified that statement with further statements. It definitely occurred for me in services running as LocalSystem on an English base OS with Japanese installed. Trying to convert from iso-2022-jp to sjis or euc-jp was a PITA in that environment, even if the same code worked in my testbed.
:-/
For many reasons that I won't explain here, the service HAD to run as localsystem. Stupid fscking developers...
The biggest concept of microkernels that I like is kernel driver isolation. There are kernels out there that let you put untrusted or misbehaving drivers into user space. This, *I* think, is one of the greatest failings of going with a monolithic kernel. Such a mechanism would in theory allow 32bit and 64bit drivers to coexist.
I love open source, but I'm not as rabid about non-binary drivers as some in the OSS movement are. Oh well. Just remember, when the HURD has critical mass, the real guts of the OSS movement (KDE, Xorg, Gnome, Evolution, Mozilla) will already be in place. Linux is just a kernel. In time, it too may see it's sunset for something better. In a way, the Hurd has it even better than Linux since a lot of the driver problems have already been solved.
I disagree. I think if they can pump out Mac Minis and can avoid the production problems that plagued the iMac, I think they can make serious inroads. The real test will be when we start seeing serious advertising begin, which leads me to think that A) they learned their lesson from the iMac debacle, and B) they haven't figured out production yet.
But it's still broken. Certain Japanese conversion functions do not work properly if you have an English version of Windows installed with Japanese Language packs installed as well. Not even setting the default locale will correct the problem. Actually, I believe it stems from the fact (or so it appears) that you cannot alter the system locale if you need to run services as NT_LOCAL_AUTHORITY\System.
Windows is fabulous. I've been a fan since 3.11 and NT 3.1 (going on 11 years now), but I've been a Unix fan just as long, and if we as a community can just get over the fact that Windows brings great technologies to the user, and our goal is to help move Linux forward through technical excellence rather than rabid evangelism.
It certainly seems to have in the case of QNX in the embedded computing space...
Could be a fluke though...
If your editor can suffice as a windows manager, it's overengineered.
No, patents still have to stand on their own and are ultimately either settled or decided by a judge. Freely giving patents to the OSS movement doesn't affect this. It just gives us patents to defend our work with.
It's one thing to unload devices from memory, I can still run /etc/init.d/hotplug stop
to prevent them from being reconnected. I'd have no need to physically disconnect the hardware before initiating a suspend/hibernate, right?