Actually, these days the critical thing is the memory access pattern. Espeically with things like ASCI Red which are really in some sense more clusters than MPP machines.
In truth, ten years from now we're not going to be doing MFLOPS to assess machine performance, or opcounts to assess algorithm performance. We're going to be looking at the number and pattern of memory accesses. Some of the IBM Power3 processors can churn out something like 4 or 6 double precision flops per clock. The question is getting a main memory bus that will *read* 96 bytes and *write* 48 bytes per CPU clock, in scatter gather, with no latency. Such a beast doesn't really exist, so Things Get Interesting.
How fast you can do something these days has a lot to do with how well you can parallelize it.
Not so fast. Sure, if one is dealing with implementation specific issues like various unices' implementation of/proc, then there are incompatibilities. The fact remains that the basic APIs and paradigms are constant across all modern Unices. Sure, the calls might be different between BSD and SvR4, and the ports are nontrivial a lot of the time, but it's not like porting between, say, MacOS and Win32s and BeOS.
As for legacy applications... iBCS, anyone? Linux can run native SCO and FreeBSD binaries, I believe.
Gosh, how about that FUD there? The last project I worked on, I used ISO C to collect data, perl for preliminary postprocessing, and Tcl/Tk for interactive final processing and display.
Would I want to use ISO C to do heavy string handling?
Would I want to use Tcl for batch-mode report summarizing?
Would I want to use perl for an interactive data viewer. (nb: perl/Tk is a bit hard to get installed on various random systems. The syntax is also not to my taste.
The chief point in all that appears above isn't that the answer is uniformly no; it is that the answer is a personal preference. What I'm most productive with is a function of my skill set and tastes. There isn't any data in what I'm replying to, just a lot of dire warnings. Bigotry over technology never got anyone anywhere.
Tcl might not have worked for this guy in this project. He hasn't given any real reasons why, though. Knowing how and why Tcl didn't work out might be interesting and useful.
Slashdot Mirror
Actually, these days the critical thing is the memory access pattern. Espeically with things like ASCI Red which are really in some sense more clusters than MPP machines.
In truth, ten years from now we're not going to be doing MFLOPS to assess machine performance, or opcounts to assess algorithm performance. We're going to be looking at the number and pattern of memory accesses. Some of the IBM Power3 processors can churn out something like 4 or 6 double precision flops per clock. The question is getting a main memory bus that will *read* 96 bytes and *write* 48 bytes per CPU clock, in scatter gather, with no latency. Such a beast doesn't really exist, so Things Get Interesting.
How fast you can do something these days has a lot to do with how well you can parallelize it.
As for legacy applications... iBCS, anyone? Linux can run native SCO and FreeBSD binaries, I believe.
- Would I want to use ISO C to do heavy string handling?
- Would I want to use Tcl for batch-mode report summarizing?
- Would I want to use perl for an interactive data viewer. (nb: perl/Tk is a bit hard to get installed on various random systems. The syntax is also not to my taste.
The chief point in all that appears above isn't that the answer is uniformly no; it is that the answer is a personal preference. What I'm most productive with is a function of my skill set and tastes. There isn't any data in what I'm replying to, just a lot of dire warnings. Bigotry over technology never got anyone anywhere.Tcl might not have worked for this guy in this project. He hasn't given any real reasons why, though. Knowing how and why Tcl didn't work out might be interesting and useful.
-BJK