Microsoft seems to be saying that they don't like the GPL used for government sponsored research because they then can't just take that software and re-sell it. Instead, what they want is that government sponsored researchers develop enhancements to Microsoft's products under shared source agreements, enhancements that will be of no commercial value to anybody but Microsoft. Seems to me Microsoft wants an extra-sweet deal from the government.
I'm quite open to the idea that governments should consider creating software under X11/BSD-style licenses. But I think working with software under Microsoft/Sun-style "shared source licenses" is completely unacceptable because those kinds of licenses favor a single vendor; this should not only be discouraged, it should be made illegal: no government sponsored researcher should be permitted to create software under such agreements. The GPL may not allow commercial use of software developed by researchers, but it is equitable and fair to all commercial competitors.
by Standardized Interface Design, i'd guess the comment was more refering to a consistent interface to the end user. It really doesn't matter what the underlying functions (toolkits etc) are, as long as everything appears standardized to the user.
I just don't see where this myth comes from: they do not "appear standardized to the user" on Windows or Macintosh, not even if we limit ourselves to mainstream applications. Windows 3.1, 95/98, NT, and XP applications all have a different look, as to things like RealOne, WinAmp, and MediaPlayer, and all of them appear on an XP desktop. And to that, you have to add the zillions of look and feel options in which people can configure their desktops completely differently, options which some applications respect and others ignore.
Ditto on Macintosh: Cocoa and Classic look completely different and feel rather different, too. The silvery i-something applications look completely different from regular applications, and InternetExplorer and RealOne are different, too. And on Macintosh, you also get the difference between Cocoa and Carbon, which is perhaps even more annoying: Cocoa and Carbon applications look very similar, but they behave completely differently in areas like key bindings.
In comparison, the variation in appearance you get among the common X11 toolkit choices (Gtk+, Qt, Tcl/Tk, wxWindows, FLTK, Motif, Athena3D) is small. The only applications that look seriously different are old 2D Athena widgets, plus a bunch of apps directly written in Xlib, but Windows has its equivalents of those, too.
I don't particularly like X11, I do find it awfully slow compared to *sigh* xp (yes I turn on a lot of eye candy effects)... Maybe this is just because X isnt making good use of openGL the same way windows uses directX. But I can *feel* the difference, in as much a quantitative as qualitative manner.
Are you just using Gnome/Gtk+, Mozilla, or KDE/Qt and assuming that their sluggish performance is due to X11? The toolkits underlying those applications are not particularly efficient (they are really written with Windows-like graphics models in mind), and those desktops have some huge and slow components.
If you want speed on X11, use something like XFCE, Blackbox, or IceWM as your desktop environment; they run very well on even very small machines.
But the reason why Gnome and KDE get by is because on most modern hardware, it really doesn't matter anymore that they waste so many cycles.
Windows applications also play costly tricks on you. Things like Office and Quicken, for example, start up processes at boot time, gobbling up lots of memory. Then, it looks like they are starting up fast. You can enable similar options for, say, Mozilla, but Linux developers really are philosophically opposed to doing that kind of thing.
but [Linux's] ease of use does leave a bit to be desired.
Based on observing family and other novices use Linux desktops, I have to disagree. If anything, KDE is less confusing to people than Windows.
t doesn't run all of the latest games,
Sure, but many people don't care. And Linux has more and better free games, which many other people do care about.
and it's not compatible with as much hardware as Windows XP.
As long as it supports all the hardware people need, that's fine. Most of the stuff that isn't supported by Linux is cheap, throw-away consumer stuff anyway. Good hardware is usually standards compliant.
Have you ever actually measured the amounts of resources the MS Windows or Macintosh window systems gobble up? X11 is lean and efficient compared to everything else out there. Microsoft keeps trying to clone X11 features, and they keep failing miserably. X11 is one of the strongest assets of Linux.
The Adoption Of A Single, Standardized Interface Design.
That's not the case on Windows, it's not the case on Macintosh, why should it be the case on Linux? Apple and Apple users are almost hysterical about "consistency", yet OS X ships with four visually and functionally highly inconsistent interfaces: Classic, Cocoa, i-something metal look, and Java. Windows is worse: you get 3.1, 95, XP, Delphi, and a host of other third party toolkits and ad-hoc hacks, all on the same desktop. The interaction style changes with every release. And have you looked at the myriad of options in which even the most basic features can be reconfigured (single click/double click, classic Explorer, etc.)? It would be hard to beat Windows for inconsistency.
Nothing, but nothing turns off a potential Linux convert than having to dig through piles of posts, to Usenet or forums like/., calling them M$ Luzors!
If that's your reason for sticking with Windows, please be my guest: stick with Windows.
Linux won't get widespread third part software support (games, educational software, bundled device drivers, turbotax, etc) until it becomes #2.
That's good as far as I'm concerned. Right now, most hardware that doesn't have Linux drivers is some weird hack anyway. I often look whether Linux drivers are available to recommend hardware for Windows. In terms of games, educational software, etc., Linux is doing fine. And tax and financial transactions are more and more handled through the web.
Now these days, the macintosh is a unix platform.
That's debatable. In many ways, OS X is more like Windows running a nice version of Cygwin than like a UNIX machines: they use HFS+, you can't access most devices through/dev, the default GUI is completely incompatible, and system management is completely different. I am happy that OS X has gone as far as it has in terms of UNIX compatibility, but an OS X machine really is no substitute for a UNIX or Linux workstation.
But right now, porting to linux without first porting to the macintosh is a really hard sell in a corporate environment,
For consumer apps, that's true. For corporate or business apps, the Macintosh is largely irrelevant, and Linux is already the next important platform after Windows.
Redhat is able to track usage of their distribution through their UpToDate software
There are too many Linux distributions for that, and many people don't see any need to update between major releases. Furthermore, the archives from which people update are mirrored across many sites.
Likewise, for Linuux, it is important to demonstrate increases in marketshare quarter over quarter in order to firmly demonstrate that the product (such as it is) remains a force to be reconed with.
Why? None of the people who pay attention to that sort of thing add anything to Linux that is of any value to me. I would prefer if desktop Linux remained under the radar screen of Microsoft and other software vendors.
It's wrong to say that "Microsoft copied the Mac GUI". There were lots of other GUIs around at the time, and both Microsoft and Macintosh copied liberally from their predecessors.
For all Macintosh OS versions combined, that's probably true. But is there any evidence to support that this is true for OS X alone? I think it is actually quite possible that Linux is already installed on more desktops than OS X.
In any case, whatever the #2 refers to today, the article, in effect, claims that installed Linux desktops will surpass the #2 next year, not that it has already surpassed it.
Perhaps they don't. If not, then why aren't they actively encouraging the best and brightest U.S. nationals to come to THEIR countries to work?
Sure they are. Trouble is, they aren't coming: given a choice, people prefer coming to the US. Language, social norms, political systems, and cultural attitudes are big obstacles for skilled foreign labor moving to places like Europe, India, or China.
Except all those countries won't let us in... will they?
Just like applying for H-1B visas, if you speak the local language, have a technical degree, and manage to get through an interview, many of them will. Germany, for example, has made 20000 H-1B work permits available recently (confusingly called "green cards"):
http://www.green-card-germany.com/germ.html
If you are out of work, I encourage you to consider it: Americans really need more experience abroad. But it won't be easy: German companies, for example, really usually are as conservative and stuffy as you probably think they are. And many European languages are a b*tch to get fluent in.
System administration, network administration, and even telephone and product support can and has all been moved overseas. Some places in China or India will even carefully train their employees to speak with an American accent.
Network connections to India and China are pathetic,
Well, what an incentive to improve them, then. Besides, the Europeans are eager to hire skilled Indian and Chinese workers and they are having trouble finding them. If the US stops scooping them up, they'll go to Europe, and Europe's infrastructure is first rate. Besides, if entire operations are moved overseas, the bandwidth required to the US becomes much less.
Norm Matloff [ucdavis.edu] gives a very detailed analysis of why the fear of jobs leaving is bogus.
Matloff starts with the incorrect assumption that companies bring skilled workers to the US because face-to-face interaction requires it. But face-to-face interaction is just as easy when entire teams move overseas.
The primary reason companies bring skilled workers to the US is because the skilled workers themselves demand it. If the US doesn't let those people in, do you think they'll start carving wooden figurines instead of doing IT work? Not a chance. Either they'll work for multinationals in their own countries, or they will found small, nimble, and efficient companies themselves and compete even more aggressively.
For the US to try to give these jobs to Americans at above world wages for skilled labor is economic suicide: if the foreign workers can't move to the US to do these jobs, the jobs will simply move out of the US, and the US will lose the tax revenue.
Unlike service sector jobs, or even manufacturing jobs, software and biotech jobs are highly mobile because they don't require a lot of equipment, all they require is skilled people. You might ask: if these jobs are so mobile, why do they all come to the US? That's probably mostly due to the preferences of the foreign workers themselves: people with a good education and skills tend to live well here. A US job is a perk for foreign workers. But if they can't get that perk because of visa restrictions, they are going to do the same job from overseas.
And think of it this way: do you really think that Europe, China, India, or Japan like it that their nationals come to the US to work here? Far from it. They call it the "brain drain" and are complaining bitterly about it. Some would dearly love to charge the US for the educational expenses of those who leave. The deal that the US has been getting out of the H-1B program is particularly sweet for the US because those are skilled workers, educated and raised at the expense of taxpayers of other nations. Europe, China, and Japan would love to see nothing more than to see the US H-1B programs restricted.
Of course, anybody can mess up anything by using LD_PRELOAD or patching the binary. But if this becomes a standard part of KDE, even KDE applications can presumably enable or disable it. And applications and frameworks that choose not to use it won't get forced to use it.
Furthermore, not putting it into the kernel is also the right thing to do from a security point of view: it defines attributes and indexes as purely user data, and it raises no new security issues.
If you put attributes and indexing into the kernel (like NT wants to), then everybody and every application pays the overhead and complexity, whether they want the feature or not. And you have additional security and permission issues as well.
Attributed and indexed file systems come up as "radical new ideas" every few years since the 1960's. Every new generation of budding CS students thinks they are the greates thing since sliced bread. I used to think so, too, until I figured out that a hierarchical file system is really a better solution--I simply had to learn how to use it.
Hierarchical file systems have become as prominent as they are because they are simple, they are efficient, they work, and they support all the indexing and attribution people need (well, that may not be true of VFAT, but it is true of modern UNIX file systems). Attribution schemes are easily mapped onto hierarchies. For example, I organize my documents and projects as ~/{work,personal}/(project)/...
But I also have other directory trees. I store stuff by keywords under "~/notes"; file names in that directory are very long, containing many words. To find something, I can search for it with "locate keyword" or "ls ~/notes | grep keyword", and to browse through it, I might use "cd ~/notes; view $(ls | grep keyword)", or "cd ~/notes; ls | grep keyword | xbrowse".
Experimental results are stored as ~/data/(experiment)/(condition)/(subcondition)/(su bsubcondition)/(measurements), and I have dozens of gigabytes of that stuff. The notion of a working directory lets me keep my data and my projects apart, and the hierarchical naming provides a quick an simple attribution scheme.
Directory trees are also easy to query in UNIX/Linux. If I don't remember whether project "foo" was personal or work-related, I can refer to it as "~/*/foo". If I'm looking for all the projects containing a particular image "img.jpg", I use something like "find ~/{work,personal} | fgrep img.jpg". Looking for any TeX file containing a particular phrase is also simple: "locate.tex | xargs grep -l phrase" for an older file and "find ~ | fgrep.tex | xargs grep -l phrase" for one I modified today. The command line utilites that UNIX and Linux come with out of the box are more powerful for indexing, attributing, and associating information than anything any commercial product or file system hack does, and they give me far more freedom in making crucial space/time tradeoffs.
These operations are not as fast as if the system had maintained indexes (well, for "locate" it does), but they are fast enough. Given that most of the time, I just want data access as quickly as possible, that's the right tradeoff as far as I'm concerned. I don't want to have to add additional metadata or pay overhead for indexes and attributions to speed up a rare and already fast operation further.
I think a lot of these efforts to add attribution and indexing to the UNIX file system are because people just don't understand the capabilities they have already at their fingertips in UNIX.
Of course, there is probably value for people working in GUI environments on Linux to get some handholding: you can't "find" or "grep" from within a GUI, so GUI-based users really need extra help. And for that purpose, a library based approach like "newdocms" is the right one. But this stuff does not belong into the kernel, at least on a general purpose OS like UNIX or Linux.
This stuff runs in user land, as a library. That's fine: applications can choose to use or not to use it.
It's a bad idea to put this sort of thing in the kernel, like Microsoft is doing: file system attributes and indexing add too much unnecessary complexity and overhead to the kernel; kernel file systems aren't used primarily for organizing user-created documents.
(You also deserved to get "bitch slapped" for calling an old and tired idea like that "radical".)
The Brain is an application that sits on top of the file system. That's not the same as an attributed, indexed file system.
I think approach taken by "The Brain" is better: no need to burden the file system with indexing and attribution. However, there is nothing unique to "The Brain"--there are plenty of other systems that create, maintain, organize, and display relationships among documents. "The Brain" just has a better marketing strategy behind it and a slicker UI.
Neither "newdocms" nor "The Brain" are any big breakthroughs. Attributed and associative information storage go back all the way to Vannevar Bush, if not before. There have been numerous attempts to implement them, mostly in research settings. The most successful one, the web itself is an experiment in associative information storage. Commercial implementations are, as usual, very late to the game and just trying to skim the cream off decades of research by others.
"When the Soviet Union tried to keep its research secret during the Cold War, their whole scientific apparatus atrophied," said former Air Force Secretary Sheila Widnall, now an aeronautics professor at MIT.
When the Soviet Union tried to keep its research secret, the research moved overseas. Restrictions on foreign nationals, visa restrictions, and secrecy are the best way for the US to ensure that research moves to Europe, Japan, and China. With secrecy, researchers won't generate the publications that advertise that a country and a lab is first rate. With visa restrictions, educated foreigners will increasingly look for jobs overseas, where they are more welcome than ever, or just stay at home and try to make things work there. Hiring restrictions on foreign nationals for "secret" projects further reduce available jobs and further drive them away.
-ffast-math should inline the trig functions. However the Pentium trig functions are not entirely standards conforming, which is why this isn't the default. The trig functions in bits/mathinline.h try to work around the limitations while still going inline.
There are several other -f options you should give if you care about maximum performance; since I don't use Pentium4, you'll have to experiment yourself and find the best combination. On my aging Athlon, this seemed to work pretty well: "-O4 -finline -mcpu=athlon -msse -ffast-math -fomit-frame-pointer -fschedule-insns -funroll-all-loops".
For inlining "sincos", you can use the sincos function from bits/mathinline.h, which attempts to be correct even for large arguments. If you want more speed, use this definition:
inline void dsincos(double &s,double &c,double a) { asm("fsincos" : "=t" (c), "=u" (s) : "0" (a)); }
Sincos should really be part of any standard numerical library; it's an odd omission that it's not in C99.
It's not entirely clear to me whether an optimizing compiler can legitimately perform this optimization itself. You might suggest it to the GNU C developers and see what they say; they may have considered and rejected it.
Please let us know what the Intel C++ compiler outputs and whether the differences really are due to the use of fsincos.
In K you always want to deal with large chuncks of like data: bulk good, scalar bad. However, there seems to be a very small class of problems where you can't write an array version of them. And this array programming methodology happens to lead to very fast code, too.
As I was saying, there is nothing special about "K", it's just like Matlab, Numerical Python, APL, A+, and lots of other tools. And your assessment that "This seems like something that would be perfect for the language." is just wrong: simulations of celestial bodies are about as ill-suited to array processing languages like "K" as can be.
That really leaves me wondering: what is your interest in "K"? It's the wrong tool for this job and there are plenty of other languages like it, many of them free and much more widely used.
Using gcc-3.2, telling it to inline the math functions and using sincos for some of the trig calls instead of separate sin/cos calls cuts execution time from 44 seconds to 29 seconds on my machine.
Maybe the Intel compiler uses sincos automatically; that would account for most of the difference.
Indeed, I think this is the root of gcc's difficulties. It doesn't invalidate the test by any means
Oh, yes, it does. If you want GNU C/C++ to inline trig functions and/or use the machine instructions, you can get it to do that, too. But there are good reasons why it doesn't do that by default. There are other options you can give GNU C/C++ to tell it to make assumptions that let it optimize more. It's really for you to decide what tradeoffs you want.
The point of using a high-level language is to avoid the need to play in assembly-land.
For day-to-day programming, I agree. But if you do benchmarks, you have to understand assembly language and look at it. There are a lot of other low-level details you need to look at and understand as well (e.g., caching). That's not so that you can tune your benchmarks for it, it's so that you can determine whether your benchmark is actually doing what you think it is doing.
The trick is picking the right level of hardware abstraction -- do you write for an assembler
Unfortunately, your code doesn't test the efficiency of abstraction at all--your code is something that could have been written in Fortran 77. Once you actually start moving to higher levels of abstraction, Fortran 95's capabilities are limited, and Java's performance becomes abysmal. Pretty much only C++ has all the necessary hooks to write efficient high-level numerical code at this point.
Note, incidentally, that even if your benchmarks are representative, the Pentium4 is probably still not the best solution in terms of price/performance. That's another important factor to be taken into account when benchmarking: how much does that performance actually cost.
(Incidentally, I hope JPL isn't using this kind of code for actual navigation.)
Matlab is a nice package, and is convenient to write, but it's mind-bogglingly slow compared to C.
Matlab is fast for operations on large arrays. That's because those operations are actually implemented in optimized C/Fortran.
I've seen speedups of 10x or more when converting Matlab code to C.
No doubt. That's probably because your Matlab code manipulated arrays via indexes and loops--that is slow. And it's slow in APL and related languages as well.
And that's my point: languages like "K" are fast in the same sense as Matlab or Numerical Python. Such languages can manipulate huge arrays of data as efficiently as Fortran or C, but they have limitations when it comes to sequential numerical code.
Looking at it briefly, the benchmark pretty much seems to test only straight line numerical code, and it seems to be dominated by calls to trigonometric functions. All the differences between the results might be explained just by how trigonometric functions are handled. GNU C always translates them into function calls, and there are good reasons for that.
The benchmark also doesn't seem to be done very carefully: I didn't see any analysis of the generated assembly language (does the Intel compiler inline the code, does it use x87 instructions for trig functions), or verification of the results (do the different programs produce the same results when compiled with different compilers), or execution profiling (what dominates the running time). These ought to be part of any new benchmark program.
First of all, it's hard to tell how the two compare. Does the Lahey compiler assume it's compiling for Pentium? Does it use inline trig functions? Does it use MMX? GNU C is very conservative about assumptions, generating code that should run anywhere by default. Give it some more machine-specific options.
Second, who cares anyway? The reason why people don't bother hacking Fortran for Linux in a big way is because the people who could contribute to such an effort are already using C++. C++ has much better abstraction facilities for numerical code than Fortran 77 and even Fortran 95. And another big chunk of the market goes to Matlab, Numerical Python, and software like that. Dusty Fortran 77 decks can be compiled adequately with f2c or g77 and linked into C++, Python, or Matlab code.
Slashdot Mirror
We are intelligent?
I'm quite open to the idea that governments should consider creating software under X11/BSD-style licenses. But I think working with software under Microsoft/Sun-style "shared source licenses" is completely unacceptable because those kinds of licenses favor a single vendor; this should not only be discouraged, it should be made illegal: no government sponsored researcher should be permitted to create software under such agreements. The GPL may not allow commercial use of software developed by researchers, but it is equitable and fair to all commercial competitors.
I just don't see where this myth comes from: they do not "appear standardized to the user" on Windows or Macintosh, not even if we limit ourselves to mainstream applications. Windows 3.1, 95/98, NT, and XP applications all have a different look, as to things like RealOne, WinAmp, and MediaPlayer, and all of them appear on an XP desktop. And to that, you have to add the zillions of look and feel options in which people can configure their desktops completely differently, options which some applications respect and others ignore.
Ditto on Macintosh: Cocoa and Classic look completely different and feel rather different, too. The silvery i-something applications look completely different from regular applications, and InternetExplorer and RealOne are different, too. And on Macintosh, you also get the difference between Cocoa and Carbon, which is perhaps even more annoying: Cocoa and Carbon applications look very similar, but they behave completely differently in areas like key bindings.
In comparison, the variation in appearance you get among the common X11 toolkit choices (Gtk+, Qt, Tcl/Tk, wxWindows, FLTK, Motif, Athena3D) is small. The only applications that look seriously different are old 2D Athena widgets, plus a bunch of apps directly written in Xlib, but Windows has its equivalents of those, too.
I don't particularly like X11, I do find it awfully slow compared to *sigh* xp (yes I turn on a lot of eye candy effects)... Maybe this is just because X isnt making good use of openGL the same way windows uses directX. But I can *feel* the difference, in as much a quantitative as qualitative manner.
Are you just using Gnome/Gtk+, Mozilla, or KDE/Qt and assuming that their sluggish performance is due to X11? The toolkits underlying those applications are not particularly efficient (they are really written with Windows-like graphics models in mind), and those desktops have some huge and slow components.
If you want speed on X11, use something like XFCE, Blackbox, or IceWM as your desktop environment; they run very well on even very small machines.
But the reason why Gnome and KDE get by is because on most modern hardware, it really doesn't matter anymore that they waste so many cycles.
Windows applications also play costly tricks on you. Things like Office and Quicken, for example, start up processes at boot time, gobbling up lots of memory. Then, it looks like they are starting up fast. You can enable similar options for, say, Mozilla, but Linux developers really are philosophically opposed to doing that kind of thing.
Based on observing family and other novices use Linux desktops, I have to disagree. If anything, KDE is less confusing to people than Windows.
t doesn't run all of the latest games,
Sure, but many people don't care. And Linux has more and better free games, which many other people do care about.
and it's not compatible with as much hardware as Windows XP.
As long as it supports all the hardware people need, that's fine. Most of the stuff that isn't supported by Linux is cheap, throw-away consumer stuff anyway. Good hardware is usually standards compliant.
Have you ever actually measured the amounts of resources the MS Windows or Macintosh window systems gobble up? X11 is lean and efficient compared to everything else out there. Microsoft keeps trying to clone X11 features, and they keep failing miserably. X11 is one of the strongest assets of Linux.
The Adoption Of A Single, Standardized Interface Design.
That's not the case on Windows, it's not the case on Macintosh, why should it be the case on Linux? Apple and Apple users are almost hysterical about "consistency", yet OS X ships with four visually and functionally highly inconsistent interfaces: Classic, Cocoa, i-something metal look, and Java. Windows is worse: you get 3.1, 95, XP, Delphi, and a host of other third party toolkits and ad-hoc hacks, all on the same desktop. The interaction style changes with every release. And have you looked at the myriad of options in which even the most basic features can be reconfigured (single click/double click, classic Explorer, etc.)? It would be hard to beat Windows for inconsistency.
Nothing, but nothing turns off a potential Linux convert than having to dig through piles of posts, to Usenet or forums like /., calling them M$ Luzors!
If that's your reason for sticking with Windows, please be my guest: stick with Windows.
That's good as far as I'm concerned. Right now, most hardware that doesn't have Linux drivers is some weird hack anyway. I often look whether Linux drivers are available to recommend hardware for Windows. In terms of games, educational software, etc., Linux is doing fine. And tax and financial transactions are more and more handled through the web.
Now these days, the macintosh is a unix platform.
That's debatable. In many ways, OS X is more like Windows running a nice version of Cygwin than like a UNIX machines: they use HFS+, you can't access most devices through /dev, the default GUI is completely incompatible, and system management is completely different. I am happy that OS X has gone as far as it has in terms of UNIX compatibility, but an OS X machine really is no substitute for a UNIX or Linux workstation.
But right now, porting to linux without first porting to the macintosh is a really hard sell in a corporate environment,
For consumer apps, that's true. For corporate or business apps, the Macintosh is largely irrelevant, and Linux is already the next important platform after Windows.
There are too many Linux distributions for that, and many people don't see any need to update between major releases. Furthermore, the archives from which people update are mirrored across many sites.
Likewise, for Linuux, it is important to demonstrate increases in marketshare quarter over quarter in order to firmly demonstrate that the product (such as it is) remains a force to be reconed with.
Why? None of the people who pay attention to that sort of thing add anything to Linux that is of any value to me. I would prefer if desktop Linux remained under the radar screen of Microsoft and other software vendors.
It's wrong to say that "Microsoft copied the Mac GUI". There were lots of other GUIs around at the time, and both Microsoft and Macintosh copied liberally from their predecessors.
In any case, whatever the #2 refers to today, the article, in effect, claims that installed Linux desktops will surpass the #2 next year, not that it has already surpassed it.
Sure they are. Trouble is, they aren't coming: given a choice, people prefer coming to the US. Language, social norms, political systems, and cultural attitudes are big obstacles for skilled foreign labor moving to places like Europe, India, or China.
Except all those countries won't let us in... will they?
Just like applying for H-1B visas, if you speak the local language, have a technical degree, and manage to get through an interview, many of them will. Germany, for example, has made 20000 H-1B work permits available recently (confusingly called "green cards"):
http://www.green-card-germany.com/germ.html
If you are out of work, I encourage you to consider it: Americans really need more experience abroad. But it won't be easy: German companies, for example, really usually are as conservative and stuffy as you probably think they are. And many European languages are a b*tch to get fluent in.
Network connections to India and China are pathetic,
Well, what an incentive to improve them, then. Besides, the Europeans are eager to hire skilled Indian and Chinese workers and they are having trouble finding them. If the US stops scooping them up, they'll go to Europe, and Europe's infrastructure is first rate. Besides, if entire operations are moved overseas, the bandwidth required to the US becomes much less.
Norm Matloff [ucdavis.edu] gives a very detailed analysis of why the fear of jobs leaving is bogus.
Matloff starts with the incorrect assumption that companies bring skilled workers to the US because face-to-face interaction requires it. But face-to-face interaction is just as easy when entire teams move overseas.
The primary reason companies bring skilled workers to the US is because the skilled workers themselves demand it. If the US doesn't let those people in, do you think they'll start carving wooden figurines instead of doing IT work? Not a chance. Either they'll work for multinationals in their own countries, or they will found small, nimble, and efficient companies themselves and compete even more aggressively.
Unlike service sector jobs, or even manufacturing jobs, software and biotech jobs are highly mobile because they don't require a lot of equipment, all they require is skilled people. You might ask: if these jobs are so mobile, why do they all come to the US? That's probably mostly due to the preferences of the foreign workers themselves: people with a good education and skills tend to live well here. A US job is a perk for foreign workers. But if they can't get that perk because of visa restrictions, they are going to do the same job from overseas.
And think of it this way: do you really think that Europe, China, India, or Japan like it that their nationals come to the US to work here? Far from it. They call it the "brain drain" and are complaining bitterly about it. Some would dearly love to charge the US for the educational expenses of those who leave. The deal that the US has been getting out of the H-1B program is particularly sweet for the US because those are skilled workers, educated and raised at the expense of taxpayers of other nations. Europe, China, and Japan would love to see nothing more than to see the US H-1B programs restricted.
Furthermore, not putting it into the kernel is also the right thing to do from a security point of view: it defines attributes and indexes as purely user data, and it raises no new security issues.
If you put attributes and indexing into the kernel (like NT wants to), then everybody and every application pays the overhead and complexity, whether they want the feature or not. And you have additional security and permission issues as well.
Hierarchical file systems have become as prominent as they are because they are simple, they are efficient, they work, and they support all the indexing and attribution people need (well, that may not be true of VFAT, but it is true of modern UNIX file systems). Attribution schemes are easily mapped onto hierarchies. For example, I organize my documents and projects as ~/{work,personal}/(project)/...
But I also have other directory trees. I store stuff by keywords under "~/notes"; file names in that directory are very long, containing many words. To find something, I can search for it with "locate keyword" or "ls ~/notes | grep keyword", and to browse through it, I might use "cd ~/notes; view $(ls | grep keyword)", or "cd ~/notes; ls | grep keyword | xbrowse".
Experimental results are stored as ~/data/(experiment)/(condition)/(subcondition)/(su bsubcondition)/(measurements), and I have dozens of gigabytes of that stuff. The notion of a working directory lets me keep my data and my projects apart, and the hierarchical naming provides a quick an simple attribution scheme.
Directory trees are also easy to query in UNIX/Linux. If I don't remember whether project "foo" was personal or work-related, I can refer to it as "~/*/foo". If I'm looking for all the projects containing a particular image "img.jpg", I use something like "find ~/{work,personal} | fgrep img.jpg". Looking for any TeX file containing a particular phrase is also simple: "locate .tex | xargs grep -l phrase" for an older file and "find ~ | fgrep .tex | xargs grep -l phrase" for one I modified today. The command line utilites that UNIX and Linux come with out of the box are more powerful for indexing, attributing, and associating information than anything any commercial product or file system hack does, and they give me far more freedom in making crucial space/time tradeoffs.
These operations are not as fast as if the system had maintained indexes (well, for "locate" it does), but they are fast enough. Given that most of the time, I just want data access as quickly as possible, that's the right tradeoff as far as I'm concerned. I don't want to have to add additional metadata or pay overhead for indexes and attributions to speed up a rare and already fast operation further.
I think a lot of these efforts to add attribution and indexing to the UNIX file system are because people just don't understand the capabilities they have already at their fingertips in UNIX.
Of course, there is probably value for people working in GUI environments on Linux to get some handholding: you can't "find" or "grep" from within a GUI, so GUI-based users really need extra help. And for that purpose, a library based approach like "newdocms" is the right one. But this stuff does not belong into the kernel, at least on a general purpose OS like UNIX or Linux.
It's a bad idea to put this sort of thing in the kernel, like Microsoft is doing: file system attributes and indexing add too much unnecessary complexity and overhead to the kernel; kernel file systems aren't used primarily for organizing user-created documents.
(You also deserved to get "bitch slapped" for calling an old and tired idea like that "radical".)
I think approach taken by "The Brain" is better: no need to burden the file system with indexing and attribution. However, there is nothing unique to "The Brain"--there are plenty of other systems that create, maintain, organize, and display relationships among documents. "The Brain" just has a better marketing strategy behind it and a slicker UI.
Neither "newdocms" nor "The Brain" are any big breakthroughs. Attributed and associative information storage go back all the way to Vannevar Bush, if not before. There have been numerous attempts to implement them, mostly in research settings. The most successful one, the web itself is an experiment in associative information storage. Commercial implementations are, as usual, very late to the game and just trying to skim the cream off decades of research by others.
When the Soviet Union tried to keep its research secret, the research moved overseas. Restrictions on foreign nationals, visa restrictions, and secrecy are the best way for the US to ensure that research moves to Europe, Japan, and China. With secrecy, researchers won't generate the publications that advertise that a country and a lab is first rate. With visa restrictions, educated foreigners will increasingly look for jobs overseas, where they are more welcome than ever, or just stay at home and try to make things work there. Hiring restrictions on foreign nationals for "secret" projects further reduce available jobs and further drive them away.
-ffast-math should inline the trig functions. However the Pentium trig functions are not entirely standards conforming, which is why this isn't the default. The trig functions in bits/mathinline.h try to work around the limitations while still going inline.
There are several other -f options you should give if you care about maximum performance; since I don't use Pentium4, you'll have to experiment yourself and find the best combination. On my aging Athlon, this seemed to work pretty well: "-O4 -finline -mcpu=athlon -msse -ffast-math -fomit-frame-pointer -fschedule-insns -funroll-all-loops".
For inlining "sincos", you can use the sincos function from bits/mathinline.h, which attempts to be correct even for large arguments. If you want more speed, use this definition:
inline void dsincos(double &s,double &c,double a) {
asm("fsincos" : "=t" (c), "=u" (s) : "0" (a));
}
Sincos should really be part of any standard numerical library; it's an odd omission that it's not in C99.
It's not entirely clear to me whether an optimizing compiler can legitimately perform this optimization itself. You might suggest it to the GNU C developers and see what they say; they may have considered and rejected it.
Please let us know what the Intel C++ compiler outputs and whether the differences really are due to the use of fsincos.
As I was saying, there is nothing special about "K", it's just like Matlab, Numerical Python, APL, A+, and lots of other tools. And your assessment that "This seems like something that would be perfect for the language." is just wrong: simulations of celestial bodies are about as ill-suited to array processing languages like "K" as can be.
That really leaves me wondering: what is your interest in "K"? It's the wrong tool for this job and there are plenty of other languages like it, many of them free and much more widely used.
Maybe the Intel compiler uses sincos automatically; that would account for most of the difference.
Oh, yes, it does. If you want GNU C/C++ to inline trig functions and/or use the machine instructions, you can get it to do that, too. But there are good reasons why it doesn't do that by default. There are other options you can give GNU C/C++ to tell it to make assumptions that let it optimize more. It's really for you to decide what tradeoffs you want.
The point of using a high-level language is to avoid the need to play in assembly-land.
For day-to-day programming, I agree. But if you do benchmarks, you have to understand assembly language and look at it. There are a lot of other low-level details you need to look at and understand as well (e.g., caching). That's not so that you can tune your benchmarks for it, it's so that you can determine whether your benchmark is actually doing what you think it is doing.
The trick is picking the right level of hardware abstraction -- do you write for an assembler
Unfortunately, your code doesn't test the efficiency of abstraction at all--your code is something that could have been written in Fortran 77. Once you actually start moving to higher levels of abstraction, Fortran 95's capabilities are limited, and Java's performance becomes abysmal. Pretty much only C++ has all the necessary hooks to write efficient high-level numerical code at this point.
Note, incidentally, that even if your benchmarks are representative, the Pentium4 is probably still not the best solution in terms of price/performance. That's another important factor to be taken into account when benchmarking: how much does that performance actually cost.
(Incidentally, I hope JPL isn't using this kind of code for actual navigation.)
Matlab is fast for operations on large arrays. That's because those operations are actually implemented in optimized C/Fortran.
I've seen speedups of 10x or more when converting Matlab code to C.
No doubt. That's probably because your Matlab code manipulated arrays via indexes and loops--that is slow. And it's slow in APL and related languages as well.
And that's my point: languages like "K" are fast in the same sense as Matlab or Numerical Python. Such languages can manipulate huge arrays of data as efficiently as Fortran or C, but they have limitations when it comes to sequential numerical code.
The benchmark also doesn't seem to be done very carefully: I didn't see any analysis of the generated assembly language (does the Intel compiler inline the code, does it use x87 instructions for trig functions), or verification of the results (do the different programs produce the same results when compiled with different compilers), or execution profiling (what dominates the running time). These ought to be part of any new benchmark program.
Second, who cares anyway? The reason why people don't bother hacking Fortran for Linux in a big way is because the people who could contribute to such an effort are already using C++. C++ has much better abstraction facilities for numerical code than Fortran 77 and even Fortran 95. And another big chunk of the market goes to Matlab, Numerical Python, and software like that. Dusty Fortran 77 decks can be compiled adequately with f2c or g77 and linked into C++, Python, or Matlab code.