Re:vectorization very rarely works
on
GCC 4.0.0 Released
·
· Score: 2, Informative
> A lot of people have done benchmarks on this, > and found out that tuning for 686 with gcc only > provides 1-2% improvements in the best case.
Uh what? It is true that i386 code runs in the ballpark on a Pentium IV, but this most definitely was not true for the Pentium III and is not true for the Pentium M. Those processors have the 4-1-1 rule, which is to say that you'll stall concurrent execution of instructions unless you arrange a complex instructions (4) with two simple ones (1). This is because there aren't enough execution units to handle any kind of instruction.
Are you really that partisan in favor the GPL? People have nasty habit of conflating issues and using the wrong words and argument to support their points but that does not directly imply their conclusion is false. http://en.wikipedia.org/wiki/Argument_from_fallacy
The LGPL exists for a reason.
Certainly, you're making a choice when you "touch" GPL licensed IP. No one "forces" you to touch GPL licensed IP.
To understand what really gets people concerned about the GPL, you have to understand what they mean by "force" and "coercion"
Man has long since past the point when one individual can practically recreate the world as a sole creator. Almost everything made today builds upon what has been made before. As more and more GPLing takes place the hold-outs increasingly get shoved into the corner. This is a form of coercion. Sure nothing forces them to join into the GPL fun but to argue they have a genuine choice is a little disingenuous.
GPL coercion is about the barriers to entry resulting from the isolating effect of the GPL licensing terms.
There is a very applicable quote here. "The law, in its majestic equality, forbids the rich as well as the poor to sleep under bridges, to beg in the streets, and to steal bread."
If you pay close attention, you'll notice that I'm using the language of monopoly here.
It is a common misconception that transistors are like switches. That explanation misses the point entirely. In digital circuits transistors are used as amplifers. Traditional computers work by charging and discharging capacitors.
Parent's parent's point about high-energy is that if your signal is strong enough to begin with, you might be able to finish the computation without amplifying it. In practice, this does not happen. Google "pass-gate" logic to learn how to use transistors as switches and how limited (and slow of a solution it is).
Second, the creators of this techology are scientists not engineers. Scientists are notoriously good at making one of something. In the real world we have to deal with parameter variations. Variability during manufacturing, variability in materials + contaminants, variability in operating conditions.
How much variablity you support relates directly to the cost. When you talk about biasing a mosfet to be an OR gate or an AND gate you give the engineer in me a heartattack.
What you're proposing is to throw-away the digital abstraction and introduce two-sided constraint assumptions. As a first guess, that seems reckless until you do a _very_ thorough analysis.
You've also not given a proposal for making an optical latch. No latch, no go--unless you're ready to dispose of the synchronous design abstraction as well.
If you're really serious about abandoning all of those assumptions, you should read "Asynchronous Pulse-Logic" (Kluwer Academic Publishers,2002) to get a feel for the formalism you have to develop to have a notion of "engineering soundness" for what you propose.
More like shove the distribution costs onto users and still change them a fee. BitTorrent is great--when the originator of the content cannot or should not be expected to foot the bandwidth costs himself.
Seriously though, they'll have a method to charge for their content (almost certainly right?) but all the expense of "shipping" that content will appear on the user's ISP costs. Sounds like a great scheme to me.
I hypothesize that, given the relatively high cost of consumer upstream bandwidth, doing this would raise the real cost of content versus distribution directly from the studios.
No, it does. The point is that each cpu is managing a different dataset. For example, a TCP connection gets mapped to a processor and stays there. All the connection dependent information for that TCP session is local on the one processor and does not consume cache resources on the other processors.
The SIDE-EFFECT is that you reduce cache-line contention + gain an additional performance gain in addition to the benefit from better utilization of your cache resources.
I wouldn't call it disillusionment. It is more impatience. I've been using FreeBSD on the desktop since 5.0-Current in 2001, the only real glitch was when they broke signal delivery in 2002.
As a desktop OS, FreeBSD is pretty healthy--the performance short-comings that still linger in 5.x are not so important on the desktop... imo.
From the installation readme:
NOTE!!! DRAGONFLY IS UNDERGOING DEVELOPMENT AND IS CONSIDERED EXPERIMENTAL! BSD RELATED EXPERIENCE IS RECOMMENDED WHEN USING THIS CDROM.
Honestly. I don't think they've advertised themselves as being anything else. They're trying to validate their kernel architecture before they needlessly start putting a lot of effort into packaging.
Note, despite being experimental, the OS is quite stable and developers are willing to fix broken port/pkg issues rapidly when they are reported. I just wouldn't expect everything to be nicely polished and "push-button" in the way that larger and more mature projects can deliver at the moment.
If you're going to run this OS, you should be willing to interact a bit on the mailing lists.
And that is precisely the people they want trying out the OS, b/c those are the people who are going to be able to submit good bug reports with kernel dumps and whatnot... and handle being asked to try patches.
None of that means anything about whether it is a good desktop OS. It is fine on the desktop, but it isn't for the inexperienced or the unwilling (yet).
And yes, you and I have spoken before on slashdot. I am aware you had a nasty experience.
DragonflyBSD is aiming to make a name in Single-System-Image distributed computing. Think Plan 9 but an evolutionary move from a well established code + user base (FreeBSD 4).
On traditional single machine installations, DragonflyBSD is being optimized for batch processing performance. The kernel is being re-architected to handle heterogenous resources. You often hear about per-cpu/per-core on their mailing lists, this is a reference to their desire to respect and avoid the high costs of IPC except when not using IPC and processor migration would itself be a penalty. You also hear a lot about cache-coherency, which is a desire to not thrash the processor caches and attempt to localize information to as few caches as possible.
If you can do this, then if you have m processors, you have m*per_cpu_cache_size fast memory. Conversely, if you aren't careful you approach having only per_cpu_cache_size of fast memory.
If it all works out (which is still an if) then you'll have an OS that is performance competitive and scales from one to hundreds of processors. This should rival FreeBSD for the performance title in the end...
And most modern operating systems already use a complex set of files to keep track of Daylight Savings rules around the world.
These files are distributed as part of Arthur Olson's timezone package. On FreeBSD see tzfile(5)
Changing the timezone rules merely requires updating one file in/usr/share/zoneinfo. Heck, congress could add a hundred different daylight savings times intervals to the year and nothing would become difficult.
If you look at the zone info stuff, you'll see that some countries do a lot of kinky stuff with their time zones.
For example see the file for south america, and argentina in particular.
I seem to recall that some years back now they had some incident with their elections and a constitutional requirement to complete the process by a certain day. The government dealt with this by passing a law to change the clocks to allow sufficient time...
Not feasible for normal e-mail clients? Our email servers do this too. Our local server tags the message with an additional header. A little mutt coloration marks these messages special, not to mention that human readible portion of the header appears right before the start of body.
As nifty as gmail is and all, most of the their "new" features have been available for years in mail clients like mutt. It's mostly a case of people not knowing to turn on the functionality that gmail is now giving everyone by default.
Well whether they tend to be true or not is hardly the point. This guy behaves as if we should just give up on blogs.
The key bit is that there are exceptions. And those exceptions gain renown. Recently there was some commentary by Orin Kerry on this subject. In particular, he was discussing how blogs run by law professors have displaced scholarly journals as the point of first analysis on new court decisions.
Now who is Oran Kerr? He's an Associate Professor of Law at George Washington University Law School. What is he blogging about? Law. Is his well informed? yes. Does he offer opinions and analysis? yes.
The real trouble is that there are so many blogs written by the run-of-the-mill person who has little claim to experience in the topic.
Who reads those blogs though? Probably not many people--until some reporter does a google run and then comments that such and such blogger had such and such opinion.
Maybe people just need to be more picky about who and what they believe.
Indeed. Even in a slow 0.18um technology, I can easily make an 8 GHz 3-inverter oscillator ring. So what?
The "chip frequency" is determined by 1) how fast can the transistors switch 2) how many FIO4 inverter equivalents (standard measure of logic complexity) there are between the latches.
#1 is just a process technology attribute
#2 is where all the magic is because it is "how much work can take place in one cycle"
#2 is commonly reduced in a technique called pipelining.
General rule: Pipelining increases throughput at the cost of latency.
Branches especially, but in other situations as well: latency becomes a limiting factor
When this happens trading against latency is a bad decision.
For any given ISA you're likely to reach this break point *somewhere*. The i386 architecture has reached it. This is because of the latency of decoding the _complex_ instructions.
A simplier instruction set => incurs less latency penalty => can be pipelined further => can achieve higher clock speeds and accrue performance benefits to additional pipelining.
Intel, though, still has probably the best process technology in the world and as a consequence if Intel were manufacturing these cell processors they'd run even faster.
But simplier instructions tend to do less work. This means you need more instructions for the same task. More instructions might code to larger memory footprints. Larger memory footprints require faster i/o to memory and larger caches to not incur performance penalties. Thus in the end you might gain nothing.
You can see this effect within amd64. Running in 64-bit mode gives you more registers, more registers should mean faster programs, but moving around all those 64-bit variables erases the benefit. (at least in compiler run-time benchmarks that I've seen).
Actually, what you call minor is what many call essential. And now you see the cultural difference. You think that it minor. Not everyone does. Especially when practically, what's important is that the binary from a year ago or two years ago or three years ago runs.
As for management time: Our department used to maintain primarily BSD (~150 machines) and with several dozen Suns and an equal numberof HP-UX machines. One part-time admin managed this configuration. Since then all the systems switched to Linux. We now have three admins who are always back-logged.
My conclusion from this + what you've said, is that neither of us has seen an stastically signifigant sample.
There is a sad reality in the VLSI industry that CAD tools from 10, 15, 20 years ago are often better for specific tasks than the modern packages from say Cadance.
The article you reference is at best dated. FreeBSD tracks security issues in ports very closely, port maintainers tend to fix them immediately or at the very least the port is marked with what's wrong. I cannot say the other BSDs do this--I don't think they do.
Thus, the allegation of organization separation is overly inflated. There are kernel people and legions of userland people and hundreds of ports maintainers without direct affiliation.
*However*, port security is monitored centerally and advisories are posted for all ports. They are however not posted in the web-page list about the base system.
Your idea though that the OS distributor should patch and maintain every possible piece of software is crazy. When selecting software for a production environment, you either 1) buy it from someone who will release bug-fix only patches or 2) select Open Source that values the same.
Also, let me take this opportunity to let you know that FreeBSD has incredibly good support for running linux binaries. You can download and install the RedHat libraries and use the redhat binaries, etc, etc.
The packaging issue is not a security issue or a bug-fix issue, it is much more about library version management. Noone yet does this right, but dragonfly has a nice basic proposal. FreeBSD's policies are an approximation closer to handing this issue (within the bounds of the base system libraries).
"Well IF you OWERWRITTEN the system libc,by hand, with another version, thats asking for trouble. And I can't see a way you should do this. If you want to have another version of lib*, and necessarily put in by hand, yoou put it in/usr/local and dynamic loader gives the program the one it needs. If you upgrade libc via a system upgrade, all apps that reference the given ABI get upgraded too."
ld simply doesn't work the way you think it does. The only way to maintain ABI and API compat is to ensure any change that breaks either of those two things is coupled to a change in the library version number. I maintain that the glibc developers do not respect this idea. Now, they would have a way out if linux supported minor library version numbers (like Sun) but linux does not.
"i have to disappoint you, debian has all this stuff and fedora core too. Automated is: installing python modules, emacs packages, info files, cron jobs, boot time startups, and more, there is unified configuration system across all packages: if a package needs a particular information, there is a unified way to ask the user for it (or not, if the user wishes, this is a configuration option of configuration system)."
No, it's a question of what is packaged up.
Many of us believe that the FreeBSD userland is superior to that available else where. In fact, that has been the entire point of my commentary. Thus, it is very unmoving for you to simply assert that they aren't interested in programming a decent userland. We obviously disagree as to what that entails. Thus, I reiterate, there is a cultural difference.
Debian's conservativism is not really relevant. The fact is that I need access to gcc >3.3 for it's c++ compliance. gcc >3.3 depends on glibc >= 2.2.5. Glibc 2.3 can not coexist on a system with glibc 2.2.5. Thus, being presented with a program that was broken with glibc > 2.2.5 I faced a problem. I assure you that Debian Stable does not resolve this conflict in any fundamental way.
Resolving it requires any of the following 1) Not breaking ABI/API within library versions 2) Permitting ld to understand minor library version numbers so that versions can be bumped for big and small changes 3) Forcing programs to be recompiled and/or souce modified.
FreeBSD is very aggressive about ensuring #1. To do that, they carefully control all the facets of the system. gcc is heavily patched on freebsd. they maintain libc themselves, etc. They ensure that the major iterations can coexist on the same system. Thus, I can install compat bits for FreeBSD 2.2, 3, 4, etc. The result being that on a brand new, gcc 3.4, freebsd libc.5 system, I can still run that binary that was built 8 years ago for FreeBSD 2.2 but whose developer has fallen off the face of the earth and taken the source with him.
Debian -STABLE does not to my knowledge offer such functionality. If you wish to argue otherwise, I'm listening...
I tried the binary route, the binary version that worked only a year ago cannot work now because of the incompatibilities introduced in the system libraries. Okay fine. So I tried the source version via the packaging system. Ooops, that's broken too. So I finally built it myself _because I had to_.
But why did I have to? What was the root issue that I was trying to highlight? The system library introduced a change that broken both ABI and API without bumping library version numbers.
There lies the point I was making. That sort change is not tolerated in the FreeBSD community. It is much more tolerated in the linux community which is why the glibc maintainers could get away with it.
Now there are lots of linux distributions, and people like Red Hat take considerable pains to protect their users against changes like that. They do this because they have lots of corporate customers who tend to take the view of the FreeBSD community.
There are also plenty of linux distributions that don't seem to care.
And the glibc people seem not to care either. And as they service most of the linux community, I alleged this indicates a cultural difference.
In my experience few linux distributions seriously care about abi and api stability. e.g.., like I've said, Red Hat seems to care but in my experience Debian and Gentoo do not.
3) At the most basic level the tools are integrated to use a common configuration system (/etc/rc.conf overriding/etc/defaults/rc.conf). This does more than simply switch programs on and off. Lots of configuration functionality is unified here. Moreover, the programs are all self-consistent. They each only depend on the features actually present and working in the other programs. e.g., a rather pedestrian example: tar has all the features in a functional state as is required by all the components in the base system.
Assurance things are done right: sshd, sendmail, bind all come preconfigured to operate using privledge seperation. Moreover these programs are integrated into the automated maintence and reporting system. e.g., sendmail integrates with the security auditing scripts to provide weekly reports and statistics of possibly suspicious activity.
Obviously you can accomplish these sorts of things using Linux, but I have yet to find a linux distribution that had done and packaged up all the work already. For me the difference is in spending hundreds of hours configurating what I now consider basic functionality versus being assured of having it right out of the box.
3a The argument is that I'd rather use something that made one way work really well and consistently than use something that gave me several choices none of which were particularly evolved.
3b The FreeBSD base system has few required components per se. More then anything the trouble is with sysinstall which is a 10 year old program that was intended only as a stop-gap when written. The consequence of this program is that a minimal install can be as you say too bulky. However, once a system is up you can merrily disable components using/etc/make.conf. e.g. You dislike bind? ok, set NO_BIND=yes.
Actually, I think what goes on is a philosphical difference rather than an inadequacy of *BSD.
First FreeBSD ports was so well regarded that someone decided to make gentoo which might well be called "FreeBSD Ports, linux style"
And here we get to the _key_ difference between the BSD culture and linux.
Recently, I downloaded some source (the pm3 compiler, ~1 year old). Much to my surprise the linux version didn't build cleanly. Why? Glibc introduced incompatibilities going from 2.2.5 to 2.3.x but the library version number was left unchanged. This forced me to spend a while fixing up the pm3 source to build against glibc 2.3.2. When I mentioned this to a friend of mine, he replied, "Well that's what you're supposed to do; that was an old outdated interface" I don't mind newer versions dropping outdated features or implementation but not when I must decide to put EITHER the new OR the old libraries on my systems.
This particular problem would never occur on a FreeBSD system. Changes like that simply are not tolerated. Breakage of that sort is confined to major releases and when that happens the library version number changes as well--allowing you to keep the old libc on your systems. Moreover, the old libc will continue to get security fixes for years.
I've often heard people complain that ports isn't very good at updating all the installed packages at once. I have almost no interest in doing this. I upgrade software selectively because I have a specific reason to do so. Updates tend to simply replace known bugs with unknown bugs and as such are not to be taken lightly. The linux breakage model simply is not acceptible in a corporate environment (it's great if you think maintaining your system is fun). This is the reason companies like redhat are slow to upgrade components and rely so heavily on internal patches.
As for your complaints about the base system versus packages. Packages are maintained not as agressively, but they are maintained. e.g., at the very least the FreeBSD security officer keeps track of vulnerabilities in ports. FreeBSD maintains a database of said vulnerabilties and my system emails me notices when a bit from ports has had a security advisory posted against it.
The base system exists: 1) To provide a self-hosting build system 2) To provide ABI, and API stability I mentioned earlier (you'll often see this as POLA - policy of least astonishment) 3) To create a set of tools which are integrated together and have known symantics. 3a) Choice simply isn't that useful to many people. e.g., I dislike that gentoo provides several different system loggers and makes no effort to have uniform and reasonable default configurations. 3b) Most of the BSD projects I am familar with are interested in creating complete systems. This is a priori missing from linux distributions because the kernel development is not well connected to any of the userlands. Redhat attemps some integration within the userland and through some patching of the kernel. But Debian or Gentoo have very minimist conceptions of a "system" which consists essentially of a packaging framework and not much else.
Overview: What you see as limitations/flaws others see as Features and Functionality. Luckily, I can have my feature and functionality running FreeBSD and you can have your knobs running whatever distribution you use.
"Having said that, when I lived in Houston (GTE then Verizon when I was there) I was always mildly amused to see that I had to pay a few cents extra for the privilege of having touch-tone dialing. Yes, touch tone dialing was an additional cost paid service."
The reason for this was regulatory. When the exchanges are upgraded to support services like Touch Tone or Caller-ID, every line supports those services--the capital cost is already sunk.
However, the tariff regulations did not permit the teleco to simply active said service and charge the extra cent per customer unformly--even though the capability was already there.
This was done because their was a congressional mandate to keep the cost of basic POTS service low--and infact often below operational costs. Thus, the oddity of being charged for touch-tone service. It was a little congressional welfare tax snuck into your telephone bill to keep the minimum cost low.
"I half-joked we'd still be dialing like this: (making circular motion) if we hadn't..."
A slow adoption of technology was never the problem with the old Bell System--quite frankly it was the opposite. AT&T and siblings tended to overinvest in the infrastructure and in introducing new technologies--the latter especially because this one of the few ways the regulatory framework would allow them increase revenues.
If you read some of the planning reports Bell Labs had developed for the Late 80s and Early 90s, you 'll see that the breakup delayed broadband by roughly a decade. Moreover, you know that POTS you're still using? That would have replaced by nationwide digital by the close of the 80s.
If you want to read (a somewhat partisan) rebutal to your assumptions, try out "The Rape of Ma Bell".
Other consequences of the breakup: the evisceration of the best research lab the world has ever known--they did basic and applied work there... gave us the transistor, microwave communications, the laser, unix, the c language, and created the field of formalized information theory and coding. They were also major uncredited contributors to the US space program--leading in particular to the development of the Telstar communication system and the first international television broadcasts in the 60s.
Sure, it was a pain that they made you buy their equipment but the Feds could have put a stop to that practice without creating the mess that has become the telecommunications industry.
And in case anyone is confused by what you said, in your example of Hank providing 911 service, the price discrimination I mentioned is illegal.
The Clayton Antitrust Act:
Sec. 13. Discrimination in price, services, or facilities ( 2 of the Clayton Act)
(a) Price; selection of customers
It shall be unlawful for any person engaged in commerce, in the course of such commerce, either directly or indirectly, to discriminate in price between different purchasers of commodities of like grade and quality,
Now, you're going to pick on whether Hank is being fair (you mention discrimination in the pejorative sense)... well there is another government regulation problem.
The trouble with the simple tax-regulation scheme you describe is that the cost structure of the government service will likely be worse at all quantities than Hank's cost structure. and Hank prefers to pursue price discrimination.
It also neglects that some people don't want any 911 service--unless price is ~zero.
Actually, what Hank would do is engage in price discrimination and charge the rich one price and the poor another.
But wait, this is an anti-trust violation. Ooops. I guess we do need a government solution to fix the situation imposed by another government regulation.
All you've discovered is that price discrimination on the part of sellers is actually a mechanism by which the economic allocations are optimized. **surprise** One price for a good is a myth created by government regulation.
I'm not a DF developer, but from what I've seen, DF is a great place to go to get help. Matt tends to be very easy to approach about issues and tends to give any real problem personal and immediate attention.
Compare this say to the way submitting bug reports to other groups yields dead silence.
Consider this: The original problem report: http://leaf.dragonflybsd.org/mailarchive/ kernel/20 04-11/msg00037.html The latest from Matt: http://leaf.dragonflybsd.org/mailarchive/ke rnel/20 04-11/msg00056.html
Mind you, this doesn't even involve an area of the project Matt has been working on.
pkg_add -r cvsup-without-gui edit the example cvsup file: so that: *default release=cvs tag=. becomes *default release=cvs tag=RELENG_5_3
Then, do the following (quoted from/usr/src/UPDATING, slightly abridged because this is will be a small upgrade):
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
make installworld
You can omit the KERNCONF business if you just want to use the GENERIC kernel.
Since you expressed a particular interest in register files, here is a recent publication:
David Fang and Rajit Manohar. Non-Uniform Access Asynchronous Register Files. Proceedings of the 10th International Symposium on Asynchronous Circuits and Systems, April 2004. http://vlsi.cornell.edu/~rajit/ps/reg.pdf The fastest/lowest energy asynchronous circuits do not use clocks for anything. Moreover, very few arbiters are used in practice. The "completion logic" of course is always the hard part, but about 10 years ago, something called "pipelined completion was developed" which alleviates that bottleneck.
For how arbiters are used and avoided: Precise Exceptions and Interrupts in Asynchronous Processors. Rajit Manohar, Mika Nystrröm, and Alain J. Martin. Proc. 21th Conference on Advanced Research in VLSI, IEEE Computer Society Press, March 2001. Crossing the Synchronous-Asynchronous Divide. Mika Nyström and Alain J. Martin. Workshop on Complexity-Effective Design, 2002
Slashdot Mirror
> A lot of people have done benchmarks on this,
> and found out that tuning for 686 with gcc only
> provides 1-2% improvements in the best case.
Uh what? It is true that i386 code runs in the ballpark on a Pentium IV, but this most definitely was not true for the Pentium III and is not true for the Pentium M. Those processors have the 4-1-1 rule, which is to say that you'll stall concurrent execution of instructions unless you arrange a complex instructions (4) with two simple ones (1). This is because there aren't enough execution units to handle any kind of instruction.
Are you really that partisan in favor the GPL? People have nasty habit of conflating issues and using the wrong words and argument to support their points but that does not directly imply their conclusion is false. http://en.wikipedia.org/wiki/Argument_from_fallacy
The LGPL exists for a reason.
Certainly, you're making a choice when you "touch" GPL licensed IP. No one "forces" you to touch GPL licensed IP.
To understand what really gets people concerned about the GPL, you have to understand what they mean by "force" and "coercion"
Man has long since past the point when one individual can practically recreate the world as a sole creator. Almost everything made today builds upon what has been made before. As more and more GPLing takes place the hold-outs increasingly get shoved into the corner. This is a form of coercion. Sure nothing forces them to join into the GPL fun but to argue they have a genuine choice is a little disingenuous.
GPL coercion is about the barriers to entry resulting from the isolating effect of the GPL licensing terms.
There is a very applicable quote here. "The law, in its majestic equality, forbids the rich as well as the poor to sleep under bridges, to beg in the streets, and to steal bread."
If you pay close attention, you'll notice that I'm using the language of monopoly here.
It is a common misconception that transistors are like switches. That explanation misses the point entirely. In digital circuits transistors are used as amplifers. Traditional computers work by charging and discharging capacitors.
Parent's parent's point about high-energy is that if your signal is strong enough to begin with, you might be able to finish the computation without amplifying it. In practice, this does not happen. Google "pass-gate" logic to learn how to use transistors as switches and how limited (and slow of a solution it is).
Second, the creators of this techology are scientists not engineers. Scientists are notoriously good at making one of something. In the real world we have to deal with parameter variations. Variability during manufacturing, variability in materials + contaminants, variability in operating conditions.
How much variablity you support relates directly to the cost. When you talk about biasing a mosfet to be an OR gate or an AND gate you give the engineer in me a heartattack.
What you're proposing is to throw-away the digital abstraction and introduce two-sided constraint assumptions. As a first guess, that seems reckless until you do a _very_ thorough analysis.
You've also not given a proposal for making an optical latch. No latch, no go--unless you're ready to dispose of the synchronous design abstraction as well.
If you're really serious about abandoning all of those assumptions, you should read "Asynchronous Pulse-Logic" (Kluwer Academic Publishers,2002) to get a feel for the formalism you have to develop to have a notion of "engineering soundness" for what you propose.
More like shove the distribution costs onto users and still change them a fee. BitTorrent is great--when the originator of the content cannot or should not be expected to foot the bandwidth costs himself.
Seriously though, they'll have a method to charge for their content (almost certainly right?) but all the expense of "shipping" that content will appear on the user's ISP costs. Sounds like a great scheme to me.
I hypothesize that, given the relatively high cost of consumer upstream bandwidth, doing this would raise the real cost of content versus distribution directly from the studios.
Who wins there?
No, it does. The point is that each cpu is managing a different dataset. For example, a TCP connection gets mapped to a processor and stays there. All the connection dependent information for that TCP session is local on the one processor and does not consume cache resources on the other processors.
The SIDE-EFFECT is that you reduce cache-line contention + gain an additional performance gain in addition to the benefit from better utilization of your cache resources.
I wouldn't call it disillusionment. It is more impatience. I've been using FreeBSD on the desktop since 5.0-Current in 2001, the only real glitch was when they broke signal delivery in 2002.
As a desktop OS, FreeBSD is pretty healthy--the performance short-comings that still linger in 5.x are not so important on the desktop... imo.
This shouldn't surprise you...
From the installation readme:
NOTE!!! DRAGONFLY IS UNDERGOING DEVELOPMENT AND IS CONSIDERED EXPERIMENTAL! BSD RELATED EXPERIENCE IS RECOMMENDED WHEN USING THIS CDROM.
Honestly. I don't think they've advertised themselves as being anything else. They're trying to validate their kernel architecture before they needlessly start putting a lot of effort into packaging.
Note, despite being experimental, the OS is quite stable and developers are willing to fix broken port/pkg issues rapidly when they are reported. I just wouldn't expect everything to be nicely polished and "push-button" in the way that larger and more mature projects can deliver at the moment.
If you're going to run this OS, you should be willing to interact a bit on the mailing lists.
And that is precisely the people they want trying out the OS, b/c those are the people who are going to be able to submit good bug reports with kernel dumps and whatnot... and handle being asked to try patches.
None of that means anything about whether it is a good desktop OS. It is fine on the desktop, but it isn't for the inexperienced or the unwilling (yet).
And yes, you and I have spoken before on slashdot. I am aware you had a nasty experience.
DragonflyBSD is aiming to make a name in Single-System-Image distributed computing. Think Plan 9 but an evolutionary move from a well established code + user base (FreeBSD 4).
On traditional single machine installations, DragonflyBSD is being optimized for batch processing performance. The kernel is being re-architected to handle heterogenous resources. You often hear about per-cpu/per-core on their mailing lists, this is a reference to their desire to respect and avoid the high costs of IPC except when not using IPC and processor migration would itself be a penalty. You also hear a lot about cache-coherency, which is a desire to not thrash the processor caches and attempt to localize information to as few caches as possible.
If you can do this, then if you have m processors, you have m*per_cpu_cache_size fast memory. Conversely, if you aren't careful you approach having only per_cpu_cache_size of fast memory.
If it all works out (which is still an if) then you'll have an OS that is performance competitive and scales from one to hundreds of processors. This should rival FreeBSD for the performance title in the end...
And most modern operating systems already use a complex set of files to keep track of Daylight Savings rules around the world.
/usr/share/zoneinfo. Heck, congress could add a hundred different daylight savings times intervals to the year and nothing would become difficult.
o neinfo/southamerica?rev=1.12.2.9&content-type=text /x-cvsweb-markup
These files are distributed as part of Arthur Olson's timezone package. On FreeBSD see tzfile(5)
Changing the timezone rules merely requires updating one file in
If you look at the zone info stuff, you'll see that some countries do a lot of kinky stuff with their time zones.
For example see the file for south america, and argentina in particular.
http://www.freebsd.org/cgi/cvsweb.cgi/src/share/z
I seem to recall that some years back now they had some incident with their elections and a constitutional requirement to complete the process by a certain day. The government dealt with this by passing a law to change the clocks to allow sufficient time...
Not feasible for normal e-mail clients? Our email servers do this too. Our local server tags the message with an additional header. A little mutt coloration marks these messages special, not to mention that human readible portion of the header appears right before the start of body.
As nifty as gmail is and all, most of the their "new" features have been available for years in mail clients like mutt. It's mostly a case of people not knowing to turn on the functionality that gmail is now giving everyone by default.
The key bit is that there are exceptions. And those exceptions gain renown. Recently there was some commentary by Orin Kerry on this subject. In particular, he was discussing how blogs run by law professors have displaced scholarly journals as the point of first analysis on new court decisions.
Now who is Oran Kerr? He's an Associate Professor of Law at George Washington University Law School. What is he blogging about? Law. Is his well informed? yes. Does he offer opinions and analysis? yes.
The real trouble is that there are so many blogs written by the run-of-the-mill person who has little claim to experience in the topic.
Who reads those blogs though? Probably not many people--until some reporter does a google run and then comments that such and such blogger had such and such opinion.
Maybe people just need to be more picky about who and what they believe.
Indeed. Even in a slow 0.18um technology, I can easily make an 8 GHz 3-inverter oscillator ring. So what?
The "chip frequency" is determined by
1) how fast can the transistors switch
2) how many FIO4 inverter equivalents (standard measure of logic complexity) there are between the latches.
#1 is just a process technology attribute
#2 is where all the magic is because it is "how much work can take place in one cycle"
#2 is commonly reduced in a technique called pipelining.
General rule: Pipelining increases throughput at the cost of latency.
Branches especially, but in other situations as well: latency becomes a limiting factor
When this happens trading against latency is a bad decision.
For any given ISA you're likely to reach this break point *somewhere*. The i386 architecture has reached it. This is because of the latency of decoding the _complex_ instructions.
A simplier instruction set => incurs less latency penalty => can be pipelined further => can achieve higher clock speeds and accrue performance benefits to additional pipelining.
Intel, though, still has probably the best process technology in the world and as a consequence if Intel were manufacturing these cell processors they'd run even faster.
But simplier instructions tend to do less work. This means you need more instructions for the same task. More instructions might code to larger memory footprints. Larger memory footprints require faster i/o to memory and larger caches to not incur performance penalties. Thus in the end you might gain nothing.
You can see this effect within amd64. Running in 64-bit mode gives you more registers, more registers should mean faster programs, but moving around all those 64-bit variables erases the benefit. (at least in compiler run-time benchmarks that I've seen).
Actually, what you call minor is what many call essential. And now you see the cultural difference. You think that it minor. Not everyone does. Especially when practically, what's important is that the binary from a year ago or two years ago or three years ago runs.
As for management time: Our department used to maintain primarily BSD (~150 machines) and with several dozen Suns and an equal numberof HP-UX machines. One part-time admin managed this configuration. Since then all the systems switched to Linux. We now have three admins who are always back-logged.
My conclusion from this + what you've said, is that neither of us has seen an stastically signifigant sample.
There is a sad reality in the VLSI industry that CAD tools from 10, 15, 20 years ago are often better for specific tasks than the modern packages from say Cadance.
The article you reference is at best dated. FreeBSD tracks security issues in ports very closely, port maintainers tend to fix them immediately or at the very least the port is marked with what's wrong. I cannot say the other BSDs do this--I don't think they do.
Thus, the allegation of organization separation is overly inflated. There are kernel people and legions of userland people and hundreds of ports maintainers without direct affiliation.
*However*, port security is monitored centerally and advisories are posted for all ports. They are however not posted in the web-page list about the base system.
Your idea though that the OS distributor should patch and maintain every possible piece of software is crazy. When selecting software for a production environment, you either 1) buy it from someone who will release bug-fix only patches
or 2) select Open Source that values the same.
Also, let me take this opportunity to let you know that FreeBSD has incredibly good support for running linux binaries. You can download and install the RedHat libraries and use the redhat binaries, etc, etc.
The packaging issue is not a security issue or a bug-fix issue, it is much more about library version management. Noone yet does this right, but dragonfly has a nice basic proposal. FreeBSD's policies are an approximation closer to handing this issue (within the bounds of the base system libraries).
"Well IF you OWERWRITTEN the system libc,by hand, with another version, thats asking for trouble. And I can't see a way you should do this. If you want to have another version of lib*, and necessarily put in by hand, yoou put it in /usr/local and dynamic loader gives the program the one it needs. If you upgrade libc via a system upgrade, all apps that reference the given ABI get upgraded too."
ld simply doesn't work the way you think it does. The only way to maintain ABI and API compat is to ensure any change that breaks either of those two things is coupled to a change in the library version number. I maintain that the glibc developers do not respect this idea. Now, they would have a way out if linux supported minor library version numbers (like Sun) but linux does not.
"i have to disappoint you, debian has all this stuff and fedora core too. Automated is: installing python modules, emacs packages, info files, cron jobs, boot time startups, and more, there is unified configuration system across all packages: if a package needs a particular information, there is a unified way to ask the user for it (or not, if the user wishes, this is a configuration option of configuration system)."
No, it's a question of what is packaged up.
Many of us believe that the FreeBSD userland is superior to that available else where. In fact, that has been the entire point of my commentary. Thus, it is very unmoving for you to simply assert that they aren't interested in programming a decent userland. We obviously disagree as to what that entails. Thus, I reiterate, there is a cultural difference.
Debian's conservativism is not really relevant. The fact is that I need access to gcc >3.3 for it's c++ compliance. gcc >3.3 depends on glibc >= 2.2.5. Glibc 2.3 can not coexist on a system with glibc 2.2.5. Thus, being presented with a program that was broken with glibc > 2.2.5 I faced a problem. I assure you that Debian Stable does not resolve this conflict in any fundamental way.
Resolving it requires any of the following
1) Not breaking ABI/API within library versions
2) Permitting ld to understand minor library version numbers so that versions can be bumped for big and small changes
3) Forcing programs to be recompiled and/or souce modified.
FreeBSD is very aggressive about ensuring #1. To do that, they carefully control all the facets of the system. gcc is heavily patched on freebsd. they maintain libc themselves, etc. They ensure that the major iterations can coexist on the same system. Thus, I can install compat bits for FreeBSD 2.2, 3, 4, etc. The result being that on a brand new, gcc 3.4, freebsd libc.5 system, I can still run that binary that was built 8 years ago for FreeBSD 2.2 but whose developer has fallen off the face of the earth and taken the source with him.
Debian -STABLE does not to my knowledge offer such functionality. If you wish to argue otherwise, I'm listening...
No. Actually I'm not.
/etc/defaults/rc.conf). This does more than simply switch programs on and off. Lots of configuration functionality is unified here. Moreover, the programs are all self-consistent. They each only depend on the features actually present and working in the other programs. e.g., a rather pedestrian example: tar has all the features in a functional state as is required by all the components in the base system.
/etc/make.conf. e.g. You dislike bind? ok, set NO_BIND=yes.
I tried the binary route, the binary version that worked only a year ago cannot work now because of the incompatibilities introduced in the system libraries. Okay fine. So I tried the source version via the packaging system. Ooops, that's broken too. So I finally built it myself _because I had to_.
But why did I have to? What was the root issue that I was trying to highlight? The system library introduced a change that broken both ABI and API without bumping library version numbers.
There lies the point I was making. That sort change is not tolerated in the FreeBSD community. It is much more tolerated in the linux community which is why the glibc maintainers could get away with it.
Now there are lots of linux distributions, and people like Red Hat take considerable pains to protect their users against changes like that. They do this because they have lots of corporate customers who tend to take the view of the FreeBSD community.
There are also plenty of linux distributions that don't seem to care.
And the glibc people seem not to care either. And as they service most of the linux community, I alleged this indicates a cultural difference.
In my experience few linux distributions seriously care about abi and api stability. e.g.., like I've said, Red Hat seems to care but in my experience Debian and Gentoo do not.
3)
At the most basic level the tools are integrated to use a common configuration system (/etc/rc.conf overriding
Assurance things are done right: sshd, sendmail, bind all come preconfigured to operate using privledge seperation. Moreover these programs are integrated into the automated maintence and reporting system. e.g., sendmail integrates with the security auditing scripts to provide weekly reports and statistics of possibly suspicious activity.
Obviously you can accomplish these sorts of things using Linux, but I have yet to find a linux distribution that had done and packaged up all the work already. For me the difference is in spending hundreds of hours configurating what I now consider basic functionality versus being assured of having it right out of the box.
3a The argument is that I'd rather use something that made one way work really well and consistently than use something that gave me several choices none of which were particularly evolved.
3b The FreeBSD base system has few required components per se. More then anything the trouble is with sysinstall which is a 10 year old program that was intended only as a stop-gap when written. The consequence of this program is that a minimal install can be as you say too bulky. However, once a system is up you can merrily disable components using
Actually, I think what goes on is a philosphical difference rather than an inadequacy of *BSD.
First FreeBSD ports was so well regarded that someone decided to make gentoo which might well be called "FreeBSD Ports, linux style"
And here we get to the _key_ difference between the BSD culture and linux.
Recently, I downloaded some source (the pm3 compiler, ~1 year old). Much to my surprise the linux version didn't build cleanly. Why? Glibc introduced incompatibilities going from 2.2.5 to 2.3.x but the library version number was left unchanged. This forced me to spend a while fixing up the pm3 source to build against glibc 2.3.2. When I mentioned this to a friend of mine, he replied, "Well that's what you're supposed to do; that was an old outdated interface" I don't mind newer versions dropping outdated features or implementation but not when I must decide to put EITHER the new OR the old libraries on my systems.
This particular problem would never occur on a FreeBSD system. Changes like that simply are not tolerated. Breakage of that sort is confined to major releases and when that happens the library version number changes as well--allowing you to keep the old libc on your systems. Moreover, the old libc will continue to get security fixes for years.
I've often heard people complain that ports isn't very good at updating all the installed packages at once. I have almost no interest in doing this. I upgrade software selectively because I have a specific reason to do so. Updates tend to simply replace known bugs with unknown bugs and as such are not to be taken lightly. The linux breakage model simply is not acceptible in a corporate environment (it's great if you think maintaining your system is fun). This is the reason companies like redhat are slow to upgrade components and rely so heavily on internal patches.
As for your complaints about the base system versus packages. Packages are maintained not as agressively, but they are maintained. e.g., at the very least the FreeBSD security officer keeps track of vulnerabilities in ports. FreeBSD maintains a database of said vulnerabilties and my system emails me notices when a bit from ports has had a security advisory posted against it.
The base system exists:
1) To provide a self-hosting build system
2) To provide ABI, and API stability I mentioned earlier (you'll often see this as POLA - policy of least astonishment)
3) To create a set of tools which are integrated together and have known symantics.
3a) Choice simply isn't that useful to many people. e.g., I dislike that gentoo provides several different system loggers and makes no effort to have uniform and reasonable default configurations.
3b) Most of the BSD projects I am familar with are interested in creating complete systems. This is a priori missing from linux distributions because the kernel development is not well connected to any of the userlands. Redhat attemps some integration within the userland and through some patching of the kernel. But Debian or Gentoo have very minimist conceptions of a "system" which consists essentially of a packaging framework and not much else.
Overview: What you see as limitations/flaws others see as Features and Functionality. Luckily, I can have my feature and functionality running FreeBSD and you can have your knobs running whatever distribution you use.
"Having said that, when I lived in Houston (GTE then Verizon when I was there) I was always mildly amused to see that I had to pay a few cents extra for the privilege of having touch-tone dialing. Yes, touch tone dialing was an additional cost paid service."
The reason for this was regulatory. When the exchanges are upgraded to support services like Touch Tone or Caller-ID, every line supports those services--the capital cost is already sunk.
However, the tariff regulations did not permit the teleco to simply active said service and charge the extra cent per customer unformly--even though the capability was already there.
This was done because their was a congressional mandate to keep the cost of basic POTS service low--and infact often below operational costs. Thus, the oddity of being charged for touch-tone service. It was a little congressional welfare tax snuck into your telephone bill to keep the minimum cost low.
"I half-joked we'd still be dialing like this: (making circular motion) if we hadn't..."
A slow adoption of technology was never the problem with the old Bell System--quite frankly it was the opposite. AT&T and siblings tended to overinvest in the infrastructure and in introducing new technologies--the latter especially because this one of the few ways the regulatory framework would allow them increase revenues.
If you read some of the planning reports Bell Labs had developed for the Late 80s and Early 90s, you 'll see that the breakup delayed broadband by roughly a decade. Moreover, you know that POTS you're still using? That would have replaced by nationwide digital by the close of the 80s.
If you want to read (a somewhat partisan) rebutal to your assumptions, try out "The Rape of Ma Bell".
Other consequences of the breakup: the evisceration of the best research lab the world has ever known--they did basic and applied work there... gave us the transistor, microwave communications, the laser, unix, the c language, and created the field of formalized information theory and coding. They were also major uncredited contributors to the US space program--leading in particular to the development of the Telstar communication system and the first international television broadcasts in the 60s.
Sure, it was a pain that they made you buy their equipment but the Feds could have put a stop to that practice without creating the mess that has become the telecommunications industry.
Indeed. Actually I own a copy of Mises's "The Theory of Money and Credit."
which I must credit for being the first analysis of Money (that I've read) that made intuitive sense.
And in case anyone is confused by what you said, in your example of Hank providing 911 service, the price discrimination I mentioned is illegal. The Clayton Antitrust Act: Sec. 13. Discrimination in price, services, or facilities ( 2 of the Clayton Act) (a) Price; selection of customers It shall be unlawful for any person engaged in commerce, in the course of such commerce, either directly or indirectly, to discriminate in price between different purchasers of commodities of like grade and quality, Now, you're going to pick on whether Hank is being fair (you mention discrimination in the pejorative sense)... well there is another government regulation problem. The trouble with the simple tax-regulation scheme you describe is that the cost structure of the government service will likely be worse at all quantities than Hank's cost structure. and Hank prefers to pursue price discrimination. It also neglects that some people don't want any 911 service--unless price is ~zero.
Actually, what Hank would do is engage in price discrimination and charge the rich one price and the poor another.
But wait, this is an anti-trust violation. Ooops. I guess we do need a government solution to fix the situation imposed by another government regulation.
All you've discovered is that price discrimination on the part of sellers is actually a mechanism by which the economic allocations are optimized. **surprise** One price for a good is a myth created by government regulation.
Before you get too enthused about forensic science. You should read and understand the prosecutors fallacy.
I'm not a DF developer, but from what I've seen, DF is a great place to go to get help. Matt tends to be very easy to approach about issues and tends to give any real problem personal and immediate attention.
/ kernel/20 04-11/msg00037.htmle rnel/20 04-11/msg00056.html
Compare this say to the way submitting bug reports to other groups yields dead silence.
Consider this:
The original problem report:
http://leaf.dragonflybsd.org/mailarchive
The latest from Matt:
http://leaf.dragonflybsd.org/mailarchive/k
Mind you, this doesn't even involve an area of the project Matt has been working on.
Best approach is to upgrade via source.
/usr/src/UPDATING, slightly abridged because this is will be a small upgrade):
pkg_add -r cvsup-without-gui
edit the example cvsup file:
so that:
*default release=cvs tag=.
becomes
*default release=cvs tag=RELENG_5_3
Then, do the following (quoted from
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
make installworld
You can omit the KERNCONF business if you just want to use the GENERIC kernel.
Since you expressed a particular interest in register files, here is a recent publication:
David Fang and Rajit Manohar. Non-Uniform Access Asynchronous Register Files. Proceedings of the 10th International Symposium on Asynchronous Circuits and Systems, April 2004.
http://vlsi.cornell.edu/~rajit/ps/reg.pdf
The fastest/lowest energy asynchronous circuits do not use clocks for anything. Moreover, very few arbiters are used in practice. The "completion logic" of course is always the hard part, but about 10 years ago, something called "pipelined completion was developed" which alleviates that bottleneck.
For how arbiters are used and avoided:
Precise Exceptions and Interrupts in Asynchronous Processors. Rajit Manohar, Mika Nystrröm, and Alain J. Martin. Proc. 21th Conference on Advanced Research in VLSI, IEEE Computer Society Press, March 2001.
Crossing the Synchronous-Asynchronous Divide. Mika Nyström and Alain J. Martin. Workshop on Complexity-Effective Design, 2002