Not really. Pretty much the first thing GPU companies do upon releasing fancy new hardware is to ship new drivers with OpenGL extensions letting developers get at the new functionality. D3D only exposes new functionality when Microsoft decide to rev the API.
This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious example right now, I don't know of any way to get at the geometry shader functionality via OpenGL. It simply doesn't fit well with the (current) OpenGL model. ATI does far fewer extensions than nVidia, though we'll have to see whether that changes with the AMD buyout.
OpenGL makes it much easier to write low-performance code, which is why there's a common speed difference. But it's not very hard at all to make up this difference if you want to. The nVidia website has a buttload of info on how to achieve this.
Yes and no -- they certainly have a lot of information, and in some cases it's quite helpful. OTOH, they still don't cover everything -- just for one obvious example, DirectX has supported instancing for quite a while. Under OpenGL, you could sort of imitate instancing, but that's about it -- and yes, nVidia has had an OpenGL "pseudo-instancing" demo for quite a while, but if you compare it to their real instancing demo that runs under DirectX, you'll quickly find that the DirectX version is still faster. I'll grant that instancing isn't the be-all and end-all of programming, but for some kinds of games, I'd bet it's quite useful (for those who aren't graphics programmers, instancing is a technique for for drawing a large number of identical or nearly identical objects more quickly than specifying each object separately).
OpenGL's also the native API of the PS3, and the majority of 3D-capable phones. Plus, every other recent console has an API very closely modelled on OpenGL.
It's true that OpenGL covers more of the market than I noted. It's also true, however, that of those, the only one that matters as a rule is probably the PS3. Getting a game to run decently on a phone (for example) involves a lot more than changing the way you display the graphics. I'm curious: when you say "every other recent console", do you have more in mind than the Wii (not to to slam the Wii -- I'm just curious what else you might have had in mind).
Another point that had been noted elsethread is that DirectX is a more comprehensive API, so a great deal more of the game becomes portable by it's being implemented on the XBox. I guess for those people running Linux on PS3's, SDL would give much of the same, but I doubt that's a large enough market for many people to care a lot about.
Maybe this is a FAQ, but could someone point us why most game developers prefer DirectX, even if, by choosing OpenGL, they'd have the possibility to develop games for other operating systems as well? Yeah, I know, Windows has over 90% of the desktop market, but why don't develop for the whole market if something like OpenGL exist?
There are a couple of reasons. First of all, Microsoft tailors the API to the latest graphics hardware much more quickly. This allows the developer to take better advantage of the latest and greatest hardware (although the hardware to support the latest spec is often quite rare, such as DirectX 10.1 hardware right now).
Second, partly as a consequence of that, you can usually do things faster under DirectX than under OpenGL, with a 2:1 speed ratio being fairly common, on identical hardware.
Third as far as portability goes: obviously you can run either under Windows. OpenGL also gives you Linux, OS/X, and a few other markets like HP/UX and Solaris mostly mean nothing from a viewpoint of selling games. DirectX gives you the XBox, which means a lot from a viewpoint of selling games.
As far as differences in the API, I can only guess that those who've gone on about how much better the DirectX API has gotten haven't really used it. DirectX started out about 10 times worse than OpenGL. It has improved, so it's now only about 5 times worse than OpenGL, but from a viewpoint of writing code, there's still no contest -- from this viewpoint, DirectX has never been close to as nice, and it still isn't.
I suppose I should add that I'm not a games programmer -- I write OpenGL code on a regular basis, and have ported some to DirectX as well, but it's all visualization software, not games.
Yes yes, and everything in C is ultimately powered by electrons, et cetera, et cetera.
I hadn't considered that, but it explains a lot. It's not really C that loves me, it's electrons that love me. I'm surrounded by a whole cloud of them! This is why people see me as so negative, even though I'm (obviously) very positive!
In case it wasn't obvious, I'm not bent out of shape about anything -- I thought the comment about how much C loves me would have made it obvious I was joking, but I guess my sense of humor is a bit on the dry side at times. My apologies.
And that's the beauty of Perl. The mechanism by which you can say you don't like Perl (slashdot) is powered by Perl. But it doesn't care, it loves you just the same.:)
It's exactly this sort of blithering nonsense that makes me want to ensure nobody mistakes me for a PERL user.
First of all, I never said I hated anything.
Second, most of the mechanism by which I expressed my opinion (the Internet) is "powered by" C and C++ a lot more than PERL.
Third, PERL itself is (of course) written in C, so everything written in PERL is really powered by C.
So, if you insist on attributing such things as love to an innocent programming language (even in jest) the real answer is that C loves me so much that even Larry and company can't screw things up, no matter how hard they try.
Neither implementation takes any resources (measurably.) And the difference in the size of the executables is 4 bytes, but that works out to a whopping.02%. Granted I didn't link static, or optimize. I tried to do a static link, but it couldn't find crt0.o, and I instantly stopped bothering.
First of all, you're measuring the wrong resources. Second, a program clearly needs to use some resources to do anything at all. Since your measurements show them all as zero, it's clear that it isn't measuring them with fine enough precision to produce meaningful results.
Your last sentence is quite telling: what you did was perfectly sensible today -- but years ago, it would not have been, which was pretty much my point from the beginning. In fact, static linking was all that was available on most systems years ago. When you use dynamic linking, you're substituting a large complex system for even attempting to make your code as small as possible -- i.e. you're basically writing exactly the sort of bloated code that started this discussion.
Now, don't get me wrong: I don't intend that as a personal accusation of wrongdoing, or anything like it -- it's a simple, practical and effective method of getting decent results with a minimum of effort. Given the cost of computer resources in general (low and dropping) vs. time and effort of programmers (high and rising), using extra machine resources to save programming time and effort makes good economic sense -- but back when computer resources were a lot more expensive, the reverse was true.
Now, if you had bothered with static linking and such, you might have found a rather more substantial difference than the.02% you mentioned. As a comparison, I did a quick bit of compiling myself. Using static linking and optimization, the version using printf came out to 23,552 bytes. By eliminating the standard library and calling the system directly, I was able to reduce that to an executable of 752 bytes. That's a reduction in size of more than 30:1.
It's obviously open to a lot of question whether that reduction is really worth the bother -- especially since it's much more difficult to get that kind of reduction for real code. OTOH, the basic point of the original article was that the author appreciated people who did bother.
Sorry, but PERL was an acronym long before the FAQ tried to deny it. At one time Larry was quite open about it; claims to the contrary came a lot later.
Then again, if it identifies me as an outsider, I'd probably capitalize it even if it wasn't an acronym. I certainly wouldn't want to be mistaken for a PERL user!
First of all, Forth (unlike PERL) is not an acronym, so it shouldn't be written in caps. Second, it's much larger than either Pax or UnLambda. Even the versions for special Forth hardware are still considerably larger than either one. UnLambda has around a half dozen operations and only one data type (the function).
Forth and assembly language are both fairly low level, but neither is (usually) particularly minimal. Obviously some assembly languages are more elaborate than others, but about the simplest of which I'm aware is the Xilinx PicoBlaze, which still has 57 instructions and 5 data types. A more typical RISC (e.g. ARM, PowerPC) supports hundreds of instructions and a dozen or more data types.
In fairness I should add that the lack of minimalism in both cases is because they're intended to be useful, which Pax and UnLambda really aren't. Granted, both (along with dozens more like them, going all the way back to Intercal) are somewhat interesting, especially in how they manage to be minimal yet (Turing) complete. Nonetheless, none of them is really intended for practical use at all. Some are simply experiments while others are explicitly intended to be the as awful as possible.
Quite the contrary! You've used printf when all you really needed was puts. For that matter, even puts hides a big, complex buffering library. If you want it bloat-free, consider something like:
main() { write(1, "hello, world", 12); }
Even though I'm (at least mostly) joking, the difference is real, and at one time would have given serious consideration to doing things this way in real code. In reality, you've shown exactly how a lot of bloat really happens. Much of it stems from people using large, general-purpose libraries where they didn't really need them. In some cases (including this one) they didn't really even gain much from the library. The C stdio library provides buffering that can help speed when/if it reduces the number of times your program calls the OS write routine. In this case, the code calls write exactly once either way, so it's gained you nothing, but cost you extra memory usage and data copying, as well as making your program quite a bit larger.
If you want minimal, try out UnLambda or Pax. Unlambda is so minimal the functions (except a few built-ins) don't even get names. As a purely functional language, it also lacks variables. Despite this, it's Turing complete, so it can do anything you can do in such bloated messes as C++, PERL or Python. Pax is also Turing complete, and the page referenced above includes complete source code to its implementation, in a total of 175 lines of code (including white space, nice indenting, etc.)
What's truly sad is that even though it was apparently invented with the specific intent of being obfuscated, Pax programs are generally much more readable than most PERL. Oh, and just to address a couple of your other points: Pax doesn't need a library to do pattern matching -- in fact, the language is basically built entirely around pattern equations. The tutorial and reference manual together work out to just over 200 lines of text. Most of that is the USTL reference manual mentioned above.
Much as I hate to, I have to admit that even compared to PERL, programs in UnLambda are somewhat obfuscated -- though once you get used to its syntax, they're not quite as bad as they initially appear (rather the opposite of PERL in that respect).
See listed spelling features. It will spell check normal language (looks like only comments) and highlight *mistyped* symbols, not mispelled symbols.
Just FWIW, it checks typing in both comments and (perhaps more importantly) string literals. It's also "intelligent" enough to know (for example) that '%d' should not be treated as a problem in a string literal. It is true, however, that symbols that are misspelled don't get highlighted, provided the misspelling is consistent.
Hmm...rereading that, I'm not sure what I was thinking of -- both OpenEXR and HD Photo (or whatever you prefer to call it) are post-processing formats, so most of what I said just doesn't apply here. I apologize.
Would someone who understands these issues please explain how this standard is similar and different to OpenEXR?
A typical digital camera arranges pixels in what's called a Bayer pattern. A typical pattern is green-red-green-blue, repeated across the image, with a one-pixel offset between rows. Note, in particular, that this means there are two green pixels for every red or blue pixel (mostly because the eye is more sensitive in the green range than red or blue). FWIW, cameras that use the Foveon sensors (e.g. Fuji's) are different: they actually have red, green and blue components for each pixel -- this is why you sometimes see them quoted as having extremely high resolutions like 20+ megapixels.
In OpenEXR, each pixel has three components: red, green and blue. Software has to take the original Bayer pattern data and convert it to this format. This involves quite a bit of interpretation on the part of the software -- i.e. there's quite a bit more than one possible way to do the job. In fact, if you look carefully, there are currently quite a few different programs out there for converting camera raw files into normal formats -- each camera manufacturer supplies their own, Adobe includes a camera raw converter with Photoshop, and then there are things like Apple Aperture, Adobe Lightroom, Bibble Pro, Capture One and Silverfast (and others I can't think of at the moment). These vary in their ability to remove artifacts, noise and so on -- for example, Bibble Pro is really good at dealing with noisy images. To do this job as well as possible, they use not only metadata from the original image, but also (in some cases) separate files to tell them about distortion and/or color shifts in particular lenses.
The bottom line is that there is not a single "right" way to convert the raw image into a format like OpenEXR. Quite the contrary, virtually any/every such conversion involves throwing away some of the original information, and takes some judgment to decide exactly which original data to keep and which to throw, as well as exactly how to combine what is kept.
Is the judicial system really qualified to test for items such as obviousness in a technical field in order to dismissing a patent. For every witness that says it is obvious, I'm sure the opposing side will say it's not. Perhaps we should have a select group of technical judges just for this purpose.
Yes, both sides are usually going to find experts who will testify to what they want said -- and to at least some extent, both will usually be correct. Relatively few patents are granted for things quite as obvious as most people think -- but most aren't exactly blazing new trails into completely unexplored wilderness (so to speak) either. The most obvious patents are rarely used as the basis for a lawsuit in any case. A company that's going to try to make money off their patents wants to look invincible -- to the point that if they send you a letter saying they think you're infringing on their patents, the only reasonable reaction is to settle as quickly as possible. The last thing they want is to waste lots of time and money in court with a weak patent, only to lose the case because it's obvious, and (worse) end up looking weaker so anybody else they go after for the next ten years (or so) will fight back because they think there's a good chance of winning.
As far as obviousness goes, there's also been a fairly noticeable change in the US recently. The Supreme Court of the US (in the case of KSR v. Teleflex) recently ruled that the criteria that have been used by the Court of Appeals for the Federal Circuit were basically flawed. The rules they had previously followed said that to show a patent was obvious, you basically needed to show where previous documents showed all the elements in the patent, and you needed to show some way in which a document suggested combining those elements into a single invention (e.g. if two elements were shown in separate documents, that a third document listed both of the first two in its bibliography).
In the KSR v. Teleflex decision, the Supreme Court ruled that it was not enough to show that the particular combination of elements you used hadn't been specifically suggested previously. Rather, you have to show that you got (for example) some result beyond what would be expected by combining those elements in that particular fashion. In case anybody cares, this ruling also discusses the criteria that had been used previously.
As far as there being a panel of judges specifically for looking at patents, that already exists: I already mentioned the Court of Appeals for the Federal Circuit. This court works almost exclusively with patent cases. It was created for more or less the reasons you suggest.
Along with ruling on things like whether a particular patent is obvious, the CAFC attempts to create criteria that give the lower courts guidance in how to make that determination as well. In KSR v. Teleflex, the Supreme Court not only changed the final ruling, but (more importantly) said that the criteria that were previously in use needed to be changed. As such, this will have a considerable effect on the rulings of lower courts in patent cases, probably for years to come.
It does seem that it's more of an encryption method than anything after reading the content of the article.
It's not really encryption either -- it's just a way of transmitting some information, and knowing whether anybody else has intercepted the transmission. The relationship to encryption is that it allows you to transmit a key and know that it wasn't intercepted during transmission. Obviously, you only use the key if it wasn't intercepted. If memory serves, it's not immune to a MITM attack though. This is why the free-air transmission means something -- it's much easier to put your agent in the middle of an optical fiber.
In the absence of public-key cryptography, this would be a big deal, as key distribution has historically been a big problem in encryption. In the presence of public key cryptography, however, the practical significance is likely to be fairly limited. In theory, if the problems associated with PK algorithms turned out to be easier than expected, this could become a big thing again -- but I see little sign of major breakthroughs in factoring, finding logarithms in a finite field, etc. Some pretty serious mathematicians have pretty solid arguments that elliptical curve encryption is probably not even amenable to the types of algorithms used for factoring and finite field algorithms (the sieve-style algorithms only work if you can prove "smoothness" and nobody's done so for elliptical curves -- and there are some fairly solid-looking arguments that they're not smooth).
So while they are at least talking about benchmark scores and actual performance (can't really talk about IPC without them), the problem is that they are leaving out the effect of frequency. In the absence of any other information, "40% more IPC" isn't really any more informative than "40% more frequency". We can guess what frequencies Barcelona might come out at, and thus make some use of this information, but it is definitely a difference from AMD's old statements.
Not really. Based on projected release dates, AMD is basically just releasing the results of simulations. They almost certainly don't have real silicon yet, and until they do, it'll be pretty hard for them to guess how fast they'll run. The design gives them a pretty fair idea of what the theoretical limit should be, but a lot less about what they can actually produce practically. Just for example, when Intel was working on Netburst, they were talking about the possibility of 10 GHz processors. Obviously, the reality fell somewhat short of that.
In addition these processors are targeted at the server market, and in the server market performance per watt often matters more than performance per system. Power consumed is generally about linear with clock speed, so in this respect a faster clock rarely does any real good. Of course, there are other contributors to power consumption, but IPC and performance per watt tend to correlate to at least some degree.
Right now, AMD undoubtedly has targets for both clock speed and power consumption, but very little real data to support any kind of announcement about either one.
It means that you can create List and pass it to a legacy method which takes only unparameterized List. Or you can get unparameterized List and cast it to parameterized type.
It's impossible to do in C#/C++.
I think saying it's impossible in C++ is a bit misleading at best. C++ has had templates since the very first version of the C++ standard. As such, at least in terms of standard C++, there's simply no version that lacks templates with which to be compatible. You can't cast std::list to some unparameterized type, because there's no unparameterized list type to which to cast it -- but if you decide to create your own StringList class (or whatever you prefer to call it) it would generally be quite trivial to make it support such a cast if you wanted to (though, of course, it's probably a poor idea to create such a class).
OTOH, back before the standard, there were some class libraries that did about like Java does, and Smalltalk did before it, with a monolithic class library rooted with Object (or something similar). When compilers added templates, some of these libraries added template front-ends for the containers that worked a lot like Java generics, basically just automatically adding casting where needed. In these cases, it was pretty easy to mix the two in about the same way as Java does.
Based on my half remembered conversations from 10 years ago, FPGAs are great for prototyping, but not for flight systems, because they are power hogs.
When you measure your power consumption in surface area of solar panel and weight of battery that need to be put on orbit...
With your typical Xilinx FPGA, power consumption would be the least of your problems. Even with unlimited power, single event upset problems would prevent them from being usable in anything you put into orbit. There have been a number of white papers written on this problem, such as from Xilinx and Altera as well as Actel (sort of) [PDF warning].
For the people talking about use only in low-volume items: I recently looked at the innards of a couple of thoroughly mass-market oriented LCD TVs that each included an FPGA. A small FPGA isn't necessarily all that expensive, and can allow things like doing a single physical design that works with either PAL or NTSC, depending purely on how you program one part...
AMD and Intel can make as many additions to x86 as they like, but if they stop supporting the existing instruction set, they'll sell nothing.
I'm not at all sure that's true. When running in 64-bit mode, support for quite a few legacy instructions disappears. For a couple of examples, you don't normally use the x87 instructions in 64-bit mode -- they're effectively replaced by SSEx instructions. Some other stuff (e.g. BCD instructions) just disappear completely, and virtually nobody notices the difference.
I'm not at all sure they'll bother to redesign the 32-bit portion to get rid of anything, but the reason has little to do with sales, and a great deal to do with justifying the effort. Since they assume essentially everybody will be running in 64-bit mode soon anyway, optimizing the 32-bit mode just doesn't make much sense. The only real improvement would be saving some die area, but decoders take up only a minute amount of die area anyway (single digit percentage the last time I looked carefully -- and probably less now).
We're bitching about the ISA here, and the sillyness with the BP register is because the x86 doesn't have an SP indexed addressing mode, so BP is needed instead to get to the passed params.
Sorry, but that's just plain wrong, and has been for quite some time. You couldn't use SP as a base register in 16-bit code, but you've been able to use ESP as a base register ever since the 386. Any decent 32-bit compiler can (and will) use ESP to access parameters.
For example, if I take code like:
int junk(int x) { return x + 1; }
and compile it with MS VC++, with:
cl/Fa/Oxb2/c trash.c
I get assembly code that looks like:
_x$ = 8 _junk PROC NEAR mov eax, DWORD PTR _x$[esp-4] inc eax ret 0 _junk ENDP
(I've elided comments, but the code is exactly as produced by the compiler)
As you can see, the parameter is accessed by indexing directly off of ESP, without using EBP at all. I should point out that there are a few instances where it's convenient to use normal stack-frames anyway -- in particular, in debugging, having a normal stack frame can make it easier to interpret a dump of the stack, but from a viewpoint of the instruction set, this "requirement" disappeared over 20 years ago.
It's truly amazing how the fact that YouTube is now owned by a company with billions of dollars suddenly means that all the content is pirated. Apparently, before Google bought them, not a single clip was even slightly shady, but ever since they started to represent billions of dollars, every clip that's ever been shown is worthy of at least one lawsuit!
Interesting that you'd mention PL/I. PL/I allowed you to use '=' for either assignment or comparison (like BASIC does). Unlike BASIC, however, it also had ':=' for assignment to deal with some ambiguous situations. One I always loved was an expression like 'x=y=0;'. Now in just about any semi-sane language this would obviously assign 0 to both x and y.
In PL/I, however, that's not what happens -- by its rules, the first '=' is an assignment, but the second is a comparison -- so it compares y to 0 and then sets x to either 0 or 1 to indicate the result. If y was 0, x becomes 1, but if y was some other value, x becomes 0. Regardless of their previous values, after executing 'x=y=0;', x cannot equal y!
As I said above, you could use ':=' to deal with this -- either 'x:=y:=0;' or "x=y:=0;' gave what you'd normally expect.
Second, in a classic case of "do what I say, not what I do", many countries are criticised for copyright laws that bear a striking similarity to US law. For example, Israel is criticised for considering a fair use provision that mirrors the US approach.
This really isn't a case of "do what I say, not what I do" -- the RIAA (for one) is actively campaigning against fair use in the US as well. They are, if nothing else, consistent.
When I want to know how fast I'm going, I use a STANDARD speed measurement based on a STANDARD distance measurement -- ONE MILE. Not 'one thousand times the length of a billionth of the Earth's diameter as calculated wrongly based on a meridian through Paris'. See how that's not a very obvious or intuitive measure?
First of all, that's not how the meter is currently defined. If memory serves, it's currently defined as the distance light travels in a particular fraction of a second. Prior to that, I believe it was defined as a multiple of the wavelength of light produced by particular type of laser (helium-neon with, IIRC, iodine as a stabilizer).
In point of fact, the meter was never defined as a fraction of the diameter of the earth -- that was more or less a basis, but the actual definition was the length of a particular bar with polished, parallel ends, held at a constant temperature, etc. That remained the standard until 1960, when it was changed to a multiple of a wavelength of light produced by a specific element. Theoretically only one element was the "true" standard, but a couple of others were accepted as secondary.
As far as the definition being the length of a physical item, that was also the case with the US system -- a foot was officially defined as the length of a particular bar of metal, held at constant temperature, etc. Actually, I believe for a while it wasn't technically the entire length of the bar, but the distance between two lines scribed into a bar, but the same general idea applies.
At the present time, I believe all of the US measurements are actually defined in terms of metric measurements. For example, the yard is defined as 0.9144 meters, and the foot as.3048 meters, etc. For anybody who cares, the U.S. NIST maintains a web site devoted to use of SI. Doing a bit of looking, they also have a time-line on the definition of the meter.
Now back to your regularly scheduled (but topical) flaming.
Slashdot Mirror
Stocks "...have reached a permanent high plateau." (Irving Fisher, October 1929).
This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious example right now, I don't know of any way to get at the geometry shader functionality via OpenGL. It simply doesn't fit well with the (current) OpenGL model. ATI does far fewer extensions than nVidia, though we'll have to see whether that changes with the AMD buyout.
Yes and no -- they certainly have a lot of information, and in some cases it's quite helpful. OTOH, they still don't cover everything -- just for one obvious example, DirectX has supported instancing for quite a while. Under OpenGL, you could sort of imitate instancing, but that's about it -- and yes, nVidia has had an OpenGL "pseudo-instancing" demo for quite a while, but if you compare it to their real instancing demo that runs under DirectX, you'll quickly find that the DirectX version is still faster. I'll grant that instancing isn't the be-all and end-all of programming, but for some kinds of games, I'd bet it's quite useful (for those who aren't graphics programmers, instancing is a technique for for drawing a large number of identical or nearly identical objects more quickly than specifying each object separately).
It's true that OpenGL covers more of the market than I noted. It's also true, however, that of those, the only one that matters as a rule is probably the PS3. Getting a game to run decently on a phone (for example) involves a lot more than changing the way you display the graphics. I'm curious: when you say "every other recent console", do you have more in mind than the Wii (not to to slam the Wii -- I'm just curious what else you might have had in mind).
Another point that had been noted elsethread is that DirectX is a more comprehensive API, so a great deal more of the game becomes portable by it's being implemented on the XBox. I guess for those people running Linux on PS3's, SDL would give much of the same, but I doubt that's a large enough market for many people to care a lot about.
There are a couple of reasons. First of all, Microsoft tailors the API to the latest graphics hardware much more quickly. This allows the developer to take better advantage of the latest and greatest hardware (although the hardware to support the latest spec is often quite rare, such as DirectX 10.1 hardware right now).
Second, partly as a consequence of that, you can usually do things faster under DirectX than under OpenGL, with a 2:1 speed ratio being fairly common, on identical hardware.
Third as far as portability goes: obviously you can run either under Windows. OpenGL also gives you Linux, OS/X, and a few other markets like HP/UX and Solaris mostly mean nothing from a viewpoint of selling games. DirectX gives you the XBox, which means a lot from a viewpoint of selling games.
As far as differences in the API, I can only guess that those who've gone on about how much better the DirectX API has gotten haven't really used it. DirectX started out about 10 times worse than OpenGL. It has improved, so it's now only about 5 times worse than OpenGL, but from a viewpoint of writing code, there's still no contest -- from this viewpoint, DirectX has never been close to as nice, and it still isn't.
I suppose I should add that I'm not a games programmer -- I write OpenGL code on a regular basis, and have ported some to DirectX as well, but it's all visualization software, not games.
I hadn't considered that, but it explains a lot. It's not really C that loves me, it's electrons that love me. I'm surrounded by a whole cloud of them! This is why people see me as so negative, even though I'm (obviously) very positive!
In case it wasn't obvious, I'm not bent out of shape about anything -- I thought the comment about how much C loves me would have made it obvious I was joking, but I guess my sense of humor is a bit on the dry side at times. My apologies.
It's exactly this sort of blithering nonsense that makes me want to ensure nobody mistakes me for a PERL user.
First of all, I never said I hated anything.
Second, most of the mechanism by which I expressed my opinion (the Internet) is "powered by" C and C++ a lot more than PERL.
Third, PERL itself is (of course) written in C, so everything written in PERL is really powered by C.
So, if you insist on attributing such things as love to an innocent programming language (even in jest) the real answer is that C loves me so much that even Larry and company can't screw things up, no matter how hard they try.
First of all, you're measuring the wrong resources. Second, a program clearly needs to use some resources to do anything at all. Since your measurements show them all as zero, it's clear that it isn't measuring them with fine enough precision to produce meaningful results.
Your last sentence is quite telling: what you did was perfectly sensible today -- but years ago, it would not have been, which was pretty much my point from the beginning. In fact, static linking was all that was available on most systems years ago. When you use dynamic linking, you're substituting a large complex system for even attempting to make your code as small as possible -- i.e. you're basically writing exactly the sort of bloated code that started this discussion.
Now, don't get me wrong: I don't intend that as a personal accusation of wrongdoing, or anything like it -- it's a simple, practical and effective method of getting decent results with a minimum of effort. Given the cost of computer resources in general (low and dropping) vs. time and effort of programmers (high and rising), using extra machine resources to save programming time and effort makes good economic sense -- but back when computer resources were a lot more expensive, the reverse was true.
Now, if you had bothered with static linking and such, you might have found a rather more substantial difference than the .02% you mentioned. As a comparison, I did a quick bit of compiling myself. Using static linking and optimization, the version using printf came out to 23,552 bytes. By eliminating the standard library and calling the system directly, I was able to reduce that to an executable of 752 bytes. That's a reduction in size of more than 30:1.
It's obviously open to a lot of question whether that reduction is really worth the bother -- especially since it's much more difficult to get that kind of reduction for real code. OTOH, the basic point of the original article was that the author appreciated people who did bother.
Sorry, but PERL was an acronym long before the FAQ tried to deny it. At one time Larry was quite open about it; claims to the contrary came a lot later.
Then again, if it identifies me as an outsider, I'd probably capitalize it even if it wasn't an acronym. I certainly wouldn't want to be mistaken for a PERL user!
First of all, Forth (unlike PERL) is not an acronym, so it shouldn't be written in caps. Second, it's much larger than either Pax or UnLambda. Even the versions for special Forth hardware are still considerably larger than either one. UnLambda has around a half dozen operations and only one data type (the function).
Forth and assembly language are both fairly low level, but neither is (usually) particularly minimal. Obviously some assembly languages are more elaborate than others, but about the simplest of which I'm aware is the Xilinx PicoBlaze, which still has 57 instructions and 5 data types. A more typical RISC (e.g. ARM, PowerPC) supports hundreds of instructions and a dozen or more data types.
In fairness I should add that the lack of minimalism in both cases is because they're intended to be useful, which Pax and UnLambda really aren't. Granted, both (along with dozens more like them, going all the way back to Intercal) are somewhat interesting, especially in how they manage to be minimal yet (Turing) complete. Nonetheless, none of them is really intended for practical use at all. Some are simply experiments while others are explicitly intended to be the as awful as possible.
main() { write(1, "hello, world", 12); }
Even though I'm (at least mostly) joking, the difference is real, and at one time would have given serious consideration to doing things this way in real code. In reality, you've shown exactly how a lot of bloat really happens. Much of it stems from people using large, general-purpose libraries where they didn't really need them. In some cases (including this one) they didn't really even gain much from the library. The C stdio library provides buffering that can help speed when/if it reduces the number of times your program calls the OS write routine. In this case, the code calls write exactly once either way, so it's gained you nothing, but cost you extra memory usage and data copying, as well as making your program quite a bit larger.
PERL lacking bloat? You've got to be kidding!
If you want minimal, try out UnLambda or Pax. Unlambda is so minimal the functions (except a few built-ins) don't even get names. As a purely functional language, it also lacks variables. Despite this, it's Turing complete, so it can do anything you can do in such bloated messes as C++, PERL or Python. Pax is also Turing complete, and the page referenced above includes complete source code to its implementation, in a total of 175 lines of code (including white space, nice indenting, etc.)
What's truly sad is that even though it was apparently invented with the specific intent of being obfuscated, Pax programs are generally much more readable than most PERL. Oh, and just to address a couple of your other points: Pax doesn't need a library to do pattern matching -- in fact, the language is basically built entirely around pattern equations. The tutorial and reference manual together work out to just over 200 lines of text. Most of that is the USTL reference manual mentioned above.
Much as I hate to, I have to admit that even compared to PERL, programs in UnLambda are somewhat obfuscated -- though once you get used to its syntax, they're not quite as bad as they initially appear (rather the opposite of PERL in that respect).
Just FWIW, it checks typing in both comments and (perhaps more importantly) string literals. It's also "intelligent" enough to know (for example) that '%d' should not be treated as a problem in a string literal. It is true, however, that symbols that are misspelled don't get highlighted, provided the misspelling is consistent.
Hmm...rereading that, I'm not sure what I was thinking of -- both OpenEXR and HD Photo (or whatever you prefer to call it) are post-processing formats, so most of what I said just doesn't apply here. I apologize.
A typical digital camera arranges pixels in what's called a Bayer pattern. A typical pattern is green-red-green-blue, repeated across the image, with a one-pixel offset between rows. Note, in particular, that this means there are two green pixels for every red or blue pixel (mostly because the eye is more sensitive in the green range than red or blue). FWIW, cameras that use the Foveon sensors (e.g. Fuji's) are different: they actually have red, green and blue components for each pixel -- this is why you sometimes see them quoted as having extremely high resolutions like 20+ megapixels.
In OpenEXR, each pixel has three components: red, green and blue. Software has to take the original Bayer pattern data and convert it to this format. This involves quite a bit of interpretation on the part of the software -- i.e. there's quite a bit more than one possible way to do the job. In fact, if you look carefully, there are currently quite a few different programs out there for converting camera raw files into normal formats -- each camera manufacturer supplies their own, Adobe includes a camera raw converter with Photoshop, and then there are things like Apple Aperture, Adobe Lightroom, Bibble Pro, Capture One and Silverfast (and others I can't think of at the moment). These vary in their ability to remove artifacts, noise and so on -- for example, Bibble Pro is really good at dealing with noisy images. To do this job as well as possible, they use not only metadata from the original image, but also (in some cases) separate files to tell them about distortion and/or color shifts in particular lenses.
The bottom line is that there is not a single "right" way to convert the raw image into a format like OpenEXR. Quite the contrary, virtually any/every such conversion involves throwing away some of the original information, and takes some judgment to decide exactly which original data to keep and which to throw, as well as exactly how to combine what is kept.
Yes, both sides are usually going to find experts who will testify to what they want said -- and to at least some extent, both will usually be correct. Relatively few patents are granted for things quite as obvious as most people think -- but most aren't exactly blazing new trails into completely unexplored wilderness (so to speak) either. The most obvious patents are rarely used as the basis for a lawsuit in any case. A company that's going to try to make money off their patents wants to look invincible -- to the point that if they send you a letter saying they think you're infringing on their patents, the only reasonable reaction is to settle as quickly as possible. The last thing they want is to waste lots of time and money in court with a weak patent, only to lose the case because it's obvious, and (worse) end up looking weaker so anybody else they go after for the next ten years (or so) will fight back because they think there's a good chance of winning.
As far as obviousness goes, there's also been a fairly noticeable change in the US recently. The Supreme Court of the US (in the case of KSR v. Teleflex) recently ruled that the criteria that have been used by the Court of Appeals for the Federal Circuit were basically flawed. The rules they had previously followed said that to show a patent was obvious, you basically needed to show where previous documents showed all the elements in the patent, and you needed to show some way in which a document suggested combining those elements into a single invention (e.g. if two elements were shown in separate documents, that a third document listed both of the first two in its bibliography).
In the KSR v. Teleflex decision, the Supreme Court ruled that it was not enough to show that the particular combination of elements you used hadn't been specifically suggested previously. Rather, you have to show that you got (for example) some result beyond what would be expected by combining those elements in that particular fashion. In case anybody cares, this ruling also discusses the criteria that had been used previously.
As far as there being a panel of judges specifically for looking at patents, that already exists: I already mentioned the Court of Appeals for the Federal Circuit. This court works almost exclusively with patent cases. It was created for more or less the reasons you suggest.
Along with ruling on things like whether a particular patent is obvious, the CAFC attempts to create criteria that give the lower courts guidance in how to make that determination as well. In KSR v. Teleflex, the Supreme Court not only changed the final ruling, but (more importantly) said that the criteria that were previously in use needed to be changed. As such, this will have a considerable effect on the rulings of lower courts in patent cases, probably for years to come.
It's not really encryption either -- it's just a way of transmitting some information, and knowing whether anybody else has intercepted the transmission. The relationship to encryption is that it allows you to transmit a key and know that it wasn't intercepted during transmission. Obviously, you only use the key if it wasn't intercepted. If memory serves, it's not immune to a MITM attack though. This is why the free-air transmission means something -- it's much easier to put your agent in the middle of an optical fiber.
In the absence of public-key cryptography, this would be a big deal, as key distribution has historically been a big problem in encryption. In the presence of public key cryptography, however, the practical significance is likely to be fairly limited. In theory, if the problems associated with PK algorithms turned out to be easier than expected, this could become a big thing again -- but I see little sign of major breakthroughs in factoring, finding logarithms in a finite field, etc. Some pretty serious mathematicians have pretty solid arguments that elliptical curve encryption is probably not even amenable to the types of algorithms used for factoring and finite field algorithms (the sieve-style algorithms only work if you can prove "smoothness" and nobody's done so for elliptical curves -- and there are some fairly solid-looking arguments that they're not smooth).
Not really. Based on projected release dates, AMD is basically just releasing the results of simulations. They almost certainly don't have real silicon yet, and until they do, it'll be pretty hard for them to guess how fast they'll run. The design gives them a pretty fair idea of what the theoretical limit should be, but a lot less about what they can actually produce practically. Just for example, when Intel was working on Netburst, they were talking about the possibility of 10 GHz processors. Obviously, the reality fell somewhat short of that.
In addition these processors are targeted at the server market, and in the server market performance per watt often matters more than performance per system. Power consumed is generally about linear with clock speed, so in this respect a faster clock rarely does any real good. Of course, there are other contributors to power consumption, but IPC and performance per watt tend to correlate to at least some degree.
Right now, AMD undoubtedly has targets for both clock speed and power consumption, but very little real data to support any kind of announcement about either one.
I think saying it's impossible in C++ is a bit misleading at best. C++ has had templates since the very first version of the C++ standard. As such, at least in terms of standard C++, there's simply no version that lacks templates with which to be compatible. You can't cast std::list to some unparameterized type, because there's no unparameterized list type to which to cast it -- but if you decide to create your own StringList class (or whatever you prefer to call it) it would generally be quite trivial to make it support such a cast if you wanted to (though, of course, it's probably a poor idea to create such a class).
OTOH, back before the standard, there were some class libraries that did about like Java does, and Smalltalk did before it, with a monolithic class library rooted with Object (or something similar). When compilers added templates, some of these libraries added template front-ends for the containers that worked a lot like Java generics, basically just automatically adding casting where needed. In these cases, it was pretty easy to mix the two in about the same way as Java does.
With your typical Xilinx FPGA, power consumption would be the least of your problems. Even with unlimited power, single event upset problems would prevent them from being usable in anything you put into orbit. There have been a number of white papers written on this problem, such as from Xilinx and Altera as well as Actel (sort of) [PDF warning].
For the people talking about use only in low-volume items: I recently looked at the innards of a couple of thoroughly mass-market oriented LCD TVs that each included an FPGA. A small FPGA isn't necessarily all that expensive, and can allow things like doing a single physical design that works with either PAL or NTSC, depending purely on how you program one part...
I'm not at all sure that's true. When running in 64-bit mode, support for quite a few legacy instructions disappears. For a couple of examples, you don't normally use the x87 instructions in 64-bit mode -- they're effectively replaced by SSEx instructions. Some other stuff (e.g. BCD instructions) just disappear completely, and virtually nobody notices the difference.
I'm not at all sure they'll bother to redesign the 32-bit portion to get rid of anything, but the reason has little to do with sales, and a great deal to do with justifying the effort. Since they assume essentially everybody will be running in 64-bit mode soon anyway, optimizing the 32-bit mode just doesn't make much sense. The only real improvement would be saving some die area, but decoders take up only a minute amount of die area anyway (single digit percentage the last time I looked carefully -- and probably less now).
Sorry, but that's just plain wrong, and has been for quite some time. You couldn't use SP as a base register in 16-bit code, but you've been able to use ESP as a base register ever since the 386. Any decent 32-bit compiler can (and will) use ESP to access parameters.
For example, if I take code like:
/Fa /Oxb2 /c trash.c
int junk(int x) { return x + 1; }
and compile it with MS VC++, with:
cl
I get assembly code that looks like:
(I've elided comments, but the code is exactly as produced by the compiler)
As you can see, the parameter is accessed by indexing directly off of ESP, without using EBP at all. I should point out that there are a few instances where it's convenient to use normal stack-frames anyway -- in particular, in debugging, having a normal stack frame can make it easier to interpret a dump of the stack, but from a viewpoint of the instruction set, this "requirement" disappeared over 20 years ago.
Well, a daft post anyway -- but certainly not the first.
It's truly amazing how the fact that YouTube is now owned by a company with billions of dollars suddenly means that all the content is pirated. Apparently, before Google bought them, not a single clip was even slightly shady, but ever since they started to represent billions of dollars, every clip that's ever been shown is worthy of at least one lawsuit!
Interesting that you'd mention PL/I. PL/I allowed you to use '=' for either assignment or comparison (like BASIC does). Unlike BASIC, however, it also had ':=' for assignment to deal with some ambiguous situations. One I always loved was an expression like 'x=y=0;'. Now in just about any semi-sane language this would obviously assign 0 to both x and y.
In PL/I, however, that's not what happens -- by its rules, the first '=' is an assignment, but the second is a comparison -- so it compares y to 0 and then sets x to either 0 or 1 to indicate the result. If y was 0, x becomes 1, but if y was some other value, x becomes 0. Regardless of their previous values, after executing 'x=y=0;', x cannot equal y!
As I said above, you could use ':=' to deal with this -- either 'x:=y:=0;' or "x=y:=0;' gave what you'd normally expect.
This really isn't a case of "do what I say, not what I do" -- the RIAA (for one) is actively campaigning against fair use in the US as well. They are, if nothing else, consistent.
First of all, that's not how the meter is currently defined. If memory serves, it's currently defined as the distance light travels in a particular fraction of a second. Prior to that, I believe it was defined as a multiple of the wavelength of light produced by particular type of laser (helium-neon with, IIRC, iodine as a stabilizer).
In point of fact, the meter was never defined as a fraction of the diameter of the earth -- that was more or less a basis, but the actual definition was the length of a particular bar with polished, parallel ends, held at a constant temperature, etc. That remained the standard until 1960, when it was changed to a multiple of a wavelength of light produced by a specific element. Theoretically only one element was the "true" standard, but a couple of others were accepted as secondary.
As far as the definition being the length of a physical item, that was also the case with the US system -- a foot was officially defined as the length of a particular bar of metal, held at constant temperature, etc. Actually, I believe for a while it wasn't technically the entire length of the bar, but the distance between two lines scribed into a bar, but the same general idea applies.
At the present time, I believe all of the US measurements are actually defined in terms of metric measurements. For example, the yard is defined as 0.9144 meters, and the foot as .3048 meters, etc. For anybody who cares, the U.S. NIST maintains a web site devoted to use of SI. Doing a bit of looking, they also have a time-line on the definition of the meter.
Now back to your regularly scheduled (but topical) flaming.