One advantage of so-called stone-age editors like Emacs and VI is that they don't clutter the screen with useless junk like toolbars, menus, project side panels, etc. I've got Emacs setup on each machine I use such that each pane, running 2 across or 3 across, almost exactly fits the width of the code based on the maximum line length called out in the coding standard we follow (giving a few characters of margin). I want as much code on the screen as possible in as large a font as is reasonable (to reduce eye strain). I also remove as much clutter vertically so that I get as many lines of code on the screen as possible.
I definitely do not want my editor to clutter my screen with menu bars, tool bars, scroll bars, project side panels, cute little multi-line consoles, big status bars, etc. that take valuable space away from the actual code window. I use my editor 8 hours every day, if not more. I know the editor's commands. I use my editor to write code, I want to see the code, not screen wasting cruft.
Some GUI editors, such as JEdit, let you remove some of the clutter; however, I have yet to see any GUI editor let you remove all of the clutter to the extent possible (or default) with Emacs or VI.
I bought a Tesla although I did look seriously at the Leaf. I also did some research on the upcoming BMW i3.
So far I've been amazed by the Tesla and in no way regret the decision to buy it. It's an incredible car.
The Leaf falls short on a number of fronts:
Unlike the Tesla which uses an induction motor tied almost directly to the wheels, the Leaf uses a synchronous motor that drives a CVT. This is crazy for several reasons:
The CVT takes up space that could otherwise be used for cargo room or for more batteries.
The CVT adds weight, again why not use that for more batteries ?
The CVT makes the car a lot more complex. One of the most beautiful aspects of an electric car is the low maintenance due to the lack of moving parts. This is less true with the Leaf.
Customers are reporting relatively rapid reduction in battery capacity in the Leaf, most notably in hot climates such as Arizona. At an effective range of 70 miles (based on what I've read from customer reviews), a 20% reduction in capacity makes the car almost unusable for me. Last thing I want is to spend $30K on a car only to have it become unusable for my daily commute after several years. I would much rather spend $90K on a car that I have confidence will last me 10 years.
When I went to the local Nissan dealer to try the Leaf, I told them that I was going to buy an EV, a gasoline car was not an option. I told them that I was considering the Leaf or Tesla and while I could manage to pay for the Tesla, the lower price tag of the Leaf was very attractive. The dealer was relatively unwilling to show me the Leaf and only let me test drive it a short distance. He insisted on talking about Nissan's other car offerings, mostly the GT-R, even after I repeatedly told him I wasn't interested in a gasoline car. After spending only a few minutes with the guy it was clear that he had absolutely no interest in selling me a Leaf.
I asked the dealer about whether Nissan could replace batteries in the Leaf and was informed that is was not really possible. I also asked about battery disposal at end of life and was told by the dealer that Nissan did not have any plan in place to deal with battery removal when the cars were scrapped.
While the BMW i3 is not on the market yet, what i've read makes me believe that it will use very similar technology to the Leaf with the only real difference being the additional of an optional small gasoline engine. Yet more complexity, more weight, and more maintenance. Exactly what I do not want to see in an EV.
If Nissan wants to compete with Tesla they're going to have to change both their mindset as well as the mindset of their dealers. I would argue that an electric car is not just a gasoline car with the gasoline engine and gas tank replaced with an electric motor + batteries. It really is a different type of vehicle that requires rethinking what a car should be from the ground up. Until Nissan, Ford, GM, etc., as well as the car dealers, figure this out, they'll be unable to compete on equal terms with Tesla in the EV market.
I also recently purchased one of these MacBooks and am running Linux on it via VMWare Fusion. I really love the hardware (not thrilled with OS-X however). I am running Scientific Linux with the KDE Trinity desktop. Works really well although I did have to adjust the font sizes and use the larger icon sizes to make it comfortable to use.
Thanks to the heavy hand and morally bankrupt behavior of the RIAA and much of the music industry, I abandoned new music all together. I simply stopped listening to it, even on the radio. I have a reasonable collection of CDs from prior to the year 2000 that I still enjoy. nI want to see the RIAA, Sony, and all the other creeps in the industry go out of business !
I don't download music off the Internet and I don't borrow CDs from anyone outside of the family. When the music industry stops lobbying to destroy our freedoms, and starts treating both their customers and the musicians with some respect I'll again start purchasing music again. Until then, the industry won't get a dime from me nor any attention. .
It will depend heavily on what path your students pursue.
I've done a mixture of hardware design and firmware development for both storage peripheral companies and IC houses. What I mostly see is:
Embedded development: Roughly a 50/50 mixture of Windows and Linux. Most compilers for embedded applications (e.g. Green Hills and ARM) are available for either platform. The same compilers are not available for Mac.
Digital IC design: Linux and some Solaris on big iron. In my experience, there is 0 use of Windows in this space. Most companies appear to be moving towards Linux.
IC verification (validating the design prior to producing the reticules used to manufacture the chips) is also 100% Linux with 0 use of Windows.
Analog IC design: Also strictly Linux and Solaris on big iron. Again, no use of Windows in this space.
Board level electrical design: Mostly Windows.
Mechanical design (Solid Works, etc.): Mostly Windows. One company I worked for used IRIX on Silicon Graphics workstations for 3D modelling, although they did eventually transition to Solid Works on Windows.
The modeling work I've seen/done (modeling Mueller-Muller clock recovery, Viterbi decoders, LDPC decoders, etc. used in communications systems) has been a 50/50 mixture of Windows and Linux (in some cases with the models developed with GCC and written to be portable across platforms). I believe this is mostly due to the compute resources that the companies I've worked for had on hand.
I have yet to see any significant use of Mac's, except as clients to log into Linux workstations. Almost all IC design and verification is done on some POSIX compliant OS because of the the requirements of the tools. IC houses I've worked for generally have large numbers of 32, 64, and 128 way multi-processor systems with huge amounts of RAM. Windows XP is simply not able to take full advantage of these large systems and the tools require this much horsepower to be effective. I also have noted that many IC designers generally seem to prefer the power of a good CLI over GUI point-in-click file managers. There is also a lot of scripting in these environments, mostly in Perl (although I've also need shell script and Python used). Linux and similar operating systems lend themselves more for this sort of work.
As for tools, I would suggest that you seriously look at trying to give your students at least a taste of such tools as MatLab, MathCAD, AutoCAD, and S. There are free equivalents for MatLab such as Scilab and Octave as well as Python packages such as SciPy, NumPy, and MatPlotLib (which I sometimes use for modeling). I know that languages such as S+ (or the free R language) are sometimes also used for statistical analysis. If you want to give your more advanced students a taste of chip design, consider the free offerings from Xilinx along with a few of their FPGA evaluation boards (available through DigiKey).
Unless your long time vegetarian or vegan, then steak truly is just disgusting.
Vegetarian for 8+ years - never once felt the desire to go back to eating warmed dead rotting animal carcass. The point is that what tastes and looks good is largely dependent on what you consider food.
Watching this video actually made me rather sad...
First Microsoft loses its ability to actually innovate: Zune = poor copy of iPod, XBox = copy of Sony, Aero = poor imitation of Compiz, etc.
Then Microsoft loses its ability to execute to at least the same level it did in the early part of the decade: Vista train-wreck, Office 2007 ribbon, performance and rendering issues, etc.
Now Microsoft loses its ability to market its products.
Even if you don't like Microsoft now, they were a great company once. Every company eventually fails. We're now witnessing the fall of one of the most successful in history.
First off, take a deep breath. I really don't want to argue and won't post further after this on this subject.
Relating to the initial conditions on the second and third, I did state at the top of my example that k>0 so the loops are functionally equivalent as far as they'll both calculate the same result for the same input.
Note that the differences in my original code was the loops. With that being said, I agree that what the compiler does inside the loop will vary and exactly how it constructs the loops may vary (I even say so and discuss in my comments). However, the number of tests and the space available for optimisation is limited in the three cases. This is inherent in how the loops are constructed. I would argue that, while the compilers may optimise differently, the structure of the loops constrains what the compilers can do (you'll also notice that the loop index does not impact the operation performed in the loop. This was by intent for the example). Again I allude to this in earlier posts.
To demonstrate the point, I took the first and third examples, encapsulated them in functions so that the compiler has limited information it can use to guess the constraints on j and k (although I did make them unsigned, I believe you'll find that the compilers would generate nearly identical code for signed integers) and compiled the code on several compilers:
- ARM RealView - THUMB2 instruction set - ARM RealView - ARM instruction set - GCC x86
In all cases, I dumped the generated assembly (using the -S switch which is common to all three compilers). I also ran the compiler using three optimisations: -O1, -02, and -O3. Instructions not related to routine entry or exit or to the j *= j++ operations have a prepended "*" (i.e. instructions used to construct the loop). I've tabulated the number of instructions associated with the looping constructs for all cases. For the THUMB2 instruction set, I also tabulated the time through each pass through the loop in clock cycles assuming no cache, zero wait-state RAM and a 3-stage instruction pipeline (which is very reasonable for these processors in an embedded system).
Here's the C code: unsigned f1(unsigned j, unsigned k); unsigned f3(unsigned j, unsigned k);
unsigned f3(unsigned j, unsigned k) { unsigned i = k; do { j *= j++ ; i--; } while (i); return j; }
Output for THUMB2, -O1: ||f1|| PROC * MOVS r2,#0 ; i = 0 * B |L1.10| ; Jump to conditional test at end of loop. |L1.4| ADDS r3,r0,#1 ; j *= j++ MULS r0,r3,r0 * ADDS r2,r2,#1 ; i++ |L1.10| * CMP r2,r1 ; Is i<k * BCC |L1.4| ; Branch if less than BX lr
I agree that I probably should have been a bit clearer in the examples, my mistake (I guess that's what I get for doing this at around 2:30 in the morning).
My intent was to give an example that would calculate (j+k)!/j! but I screwed up and the code actually calculates (j+k-1)!/j!. If j=1, you'll see that the code calculates k!.
What I was driving at was in how the compiler would tend to construct the loops (without apriori knowledge of the constraints on the integers j and k.).
In the first example, the test occurs prior to entering the loop and the comparison is against k. With most compilers, the resulting assembly code (written as a generic assembly language) would be something akin to:
move i,#0 jump test loop: multiply j,j,j increment j test: increment i compare i,k branch_if_less_than loop
I have also seen compilers (such as some old Keil Franklin compilers) construct the loop differently so that it can place the test at the top, either doing the test twice or adding a jump at the bottom of the loop back to the test.
In the second example, the test occurs at the top but the comparison is against zero. This will often optimize the code above by removing the need for the compare instruction:
move i,k jump test loop: multiply j,j,j increment j test: decrement i branch_if_not_zero loop
Note that this statement is not always universal. There are some processors that don't set flags on an inc/dec instructions and therefore still need the compare operation. Also, some processors, such as Z80 have a DJNZ instruction that combines the decrement and the branch if non-zero instruction into a single opcode.
Also note that the second example may also be able avoid the move instruction at the top if the value of k is not needed after this segment of code executes.
The third example removes the need for the jump instruction:
Again, the compiler may be able to remove the move instruction at the top if it has no use for k after this code segment.
The 20% number I quoted was based on past experience with similar sorts of tight loops on ARM 9 and ARM Cortex-M3.
Relating to using the compiler as a macro language, I did not mean to imply that you ignore the abstraction that the high level language gives you (intent of my comment about maintainability), only that you write the code being very mindful of the output and optimise your source code to help the compiler optimise it's output, as I tried to show with the loops. This is never done in a vacuum, you both learn how the compiler does it's optimisation and also review what the compiler actually generates for those time critical sections of code that you really care about (typically by single stepping using an in circuit emulator, trace-port analyser or, in some cases, a simulator).
As a firmware/electrical (as opposed to software) engineer, I used to write in assembly language almost exclusively (on deeply embedded 8-bit microcontrollers with very limited resources. I still occassionally write some very time critical assembly code for 32-bit ARM processors). I can state for a fact that there is tremendous value in having a good understanding of and experience coding assembly languages, even today:
If you know assembly, you can much more easily understand the trade-offs between different, functionally identical, high level constructs. As a simple example, consider the follow three slighly contrived snippets of C code. In all three examples, k > 0:
for (i=0 ; i<k ; i++) j = j*(j++);
versus:
for (i=k ; i ; i--) j = j*(j++);
versus:
i = k ; do { j = j*(j++) ; i--; } while (i);
On most architectures, the first will generally be least efficient and the third will generally be most efficient (often by as much as 20%), why ?
If you have a good understanding of assembly language, you view high level languages differently. Instead of viewing high level languages as an abstract syntax, you view them in terms of how they translate to the underlying machine code. This actually makes it easier to learn new languages because you must more easily understand the rationale behind many choices that were made in defining the language.
Embedded developers (at least me) when developing time-critical code, often think of the C/C++ compiler as a macro language on top of an assembler and write the C/C++ code based on the underlying assembly code we want the compiler to generate. That is, we view the high level language in terms of the machine code it generates, not in terms of the strict syntactic rules (although we write knowing the code must also be maintainable).
There are a number of "tricks" that you learn after writing assembly that are useful when writing higher level languages. These "tricks" are almost never taught in school and are rarely seen in high level code. As an example, what's the fastest and most concise way to check if an integer is a power of 2 (for arbitrarily large integers) ? How about:
if (0 == ((i+1)^i)&i) {/* A power of 2 */ }
There are in fact a large number of tricks like this, a number of them can be derived by examining the basic boolean expressions that define binary addition (and subtraction) with carry.
If you've written some assembly code, you quickly understand in a fundamental way, how software and hardware interacts.
While you can argue that an understanding of assembly is less valuable for application programmers because machines are "fast enough", there are certainly cases where shaving 20% off a tight loop can be noticeable to the user. Also, writing application programs is only one facet of the larger discipline of computer science/computer engineering. People that work with real-time systems or develop operating systems (especially on cost sensitive products), by necessity, do make use of these skills. Because of the push to always lower costs, processor resources on deeply embedded systems will generally always be sized to be just big enough and therefore niche needs for these skills will never disappear (at least it hasn't in the 29+ years I've been doing this sort of work).
Sorry, but based on my experience, I disagree with the point of this article.
I find both Gnome and KDE far more usable than the commercial offerings that are available. Specifically, I find the following features really useful:
Multiple desktops (with the ability to switch quickly), why limit yourself to 1 view into your system when you can have 4, 8 or more views. More effective screeen real-estate means less time spent moving windows around.
Always on top (great when used with calculator applications and the like)
The ability to roll a window up (sometimes called shading). Allows you to see what's under a window with less mouse movement. Also useful in conjunction with always on top to dock a window in a convenient location and still be able to get to it with less mouse movement.
These are features that I have yet to see on a widely used commercial offering out of the box and features that I find really boost my productivity. Yes, there are commercial add-ons (such as StarDock), but they're buggy as all get out and generally suck compared to what I can get on a standard Linux install. One feature that generally makes me tend towards KDE over Gnome is the ability to place the taskbar on the side of the screen instead of the bottom and still have something that is very usable. When you write lots of code, you want more height, not width. Wide screens are great for multimedia but are generally poor for code development. For coders, placing the taskbar on the bottom makes less efficient use of the screen.
Relating to innovation, the FOSS movement has certainly been the source for lots of innovation. This "lack of innovation" seems to be a recent mantra being thrown out against the FOSS movement. Consider:
Beowulf
GL desktop effects a.k.a. Compiz or Beryl (and largely imitated by Aero and OSX).
All the many, many, innovations behind Perl, Python, and Ruby languages.
JavaScript, started with the Mozilla browser. JavaScript is largely what underpins "web 2.0".
All the other innovations introduced by Mozilla, such as tabbed browsing
Apache -- I would argue to IIS and the like are still playing catch-up with Apache and are really just me-too products that are trying to be a better Apache.
Ruby and Rails and similar model-view-controller style web interfaces.
Konqueror, the idea that a single tool using plug-ins can be a generic viewer of all types of media, including websites.
I see many small user interface paradigms that were introduced originally in early versions of Gnome or KDE and later copied by Microsoft in releases of XP and Vista.
ODF -- More specifically the idea of a universal, editable, document format.
Quake style terminals for general use of a shell, I have yet to see this on a commercial desktop for anything other than games.
Jabber
BLAS -- Underpins most commercial and FOSS mathematics packages
...
Sorry to burst the article's bubble, but FOSS has been the source for a huge amount of innovation. What I see coming from the commercial offerings has been, to a large extent, an apeing or imitation of ideas started by the FOSS movement with some incremental improvement on the original idea.
Within days of Word 97 coming out on the market, I attempted to print a document with a footer containing the page number and number of pages. Word 97 would screw up the page count the first time it would print a document so pages with page number of the form 1 of N, 2 of N, etc. would come out as 1 of 1, 2 of 2, etc.
I contacted MS through my company's support contract to find out that they were aware it was broken and their solution was that I should not use this feature. I continued to use the feature but always printed to a file prior to printing for real to get the page count correct.
Asked if they were going to supply a patch. Received a simple No, Asked if they would fix it in the next release, the person on the phone again indicated simply that they had no plan to fix it.
Several weeks later I called asking if there was anything that could be done to keep the equation editor from crashing when I used it. I received the exact same set of answers.
Lots of anti-party sentiment on/. and for good reason. Question is, as law abiding citizens of the US (and other countries with similar problems), what do we do to solve the problem.
It's easy to gripe but griping does no good. May I suggest that we start looking for a solution rather than just complaining about the problem.
The solution to treaties like the ACTA as well as laws like the DMCA is simple:
Stop violating copyrights (so that the *AA have no leg to stand on legally).
Stop buying copyrighted material from companies that support the treaties such as ACTA as well as laws like the DMCA (to drive the *AA supporting members out of business).
The only way to stop the stupidity is to pull the rug out from under the corporations and organizations that support this stupidity in the first place, both financially and legally.
Besides, how many songs or recent movies are worth the plastic they're distributed on anyway ?
To AcidPenguin9873: You're comment is really on a larger subject than treaties like the ACTA and DMCA. You're right that western cultures are moving towards an information based economy. A big part of the problem is that the existing laws help the large players in the entertainment industry but cripple smaller players and also cripple other industries. Therefore, these treaties and laws are really not beneficial to our society as a whole. The laws also marginalize existing rights under copyright: first sale rights and fair use rights, both of which are important to allow commerce on used material continue and to allow commentary, satire and, in some cases, innovation.
Why: For the most part, at least in engineering and also to a somewhat lesser extent in entertainment, every new idea (or song, or movie plot) is simply a rehashing of existing ideas with some new wrinkle or improvement. Innovation is almost always incremental, not revolutionary. I have seen this over and over at multiple employers over my 30 year career (I used to work in professional audio, I now work in data storage).
For one product I worked on, legal pared down the number of possibly infringing patents to over 60,000 which a team of 20 of us spent months reviewing over evenings and weekends while also working on product development. Of that 60,000, roughly 100 actually overlapped what we were working on in some way and caused us to find ways to work around them or cross-license them.
Question: What happens when this number of patents (or trademarks, copyrights) increases 100 fold ?
Question: How will smaller players and start-ups ever be able to compete if they must cross-license with a larger player that does not want them in the market ? The chance of this occuring increases with the number of companies that the small player must negotiate with which also increases with the number of overlapping patents.
Question: Given how the laws are going and if the number of patents, and/or copyright increases substantially (which will happen in an information society), how can smaller players with limited cash flow successfully compete with larger players with much greater cash flow.
Point is that, should such a society develop with the laws moving in the direction they're moving (and assuming their fully enforced):
Innovation will effectively stop, except at large companies with cross-licensing agreements or large defensive portfolios, because the task of working around existing ideas when trying to develop something that incrementally improves on other products in an industry will become impossibly daunting.
Small innovative companies will no longer be able to exist in high-tech or entertainment because they will be unable to navigate the legal minefield created by the volume of (mostly poor quality) patents, trademarks, and/or copyrights produced by larger players. I have already seen, first hand, cases of small start-ups failing because of this.
Companies in countries that decide to selectively refuse to accept some apect of a treaty or simply not enforce those treaties after accepting them will have a clear advantage in the world-wide markets those companies play in. For a clear example of this right now, look at China.
While protection of ideas and content is important for
Slashdot Mirror
I would also highly recommend the litter robot. I've had one in my house for several years now and it's been fantastic.
I have yet to see anyone comment on this...
One advantage of so-called stone-age editors like Emacs and VI is that they don't clutter the screen with useless junk like toolbars, menus, project side panels, etc. I've got Emacs setup on each machine I use such that each pane, running 2 across or 3 across, almost exactly fits the width of the code based on the maximum line length called out in the coding standard we follow (giving a few characters of margin). I want as much code on the screen as possible in as large a font as is reasonable (to reduce eye strain). I also remove as much clutter vertically so that I get as many lines of code on the screen as possible.
I definitely do not want my editor to clutter my screen with menu bars, tool bars, scroll bars, project side panels, cute little multi-line consoles, big status bars, etc. that take valuable space away from the actual code window. I use my editor 8 hours every day, if not more. I know the editor's commands. I use my editor to write code, I want to see the code, not screen wasting cruft.
Some GUI editors, such as JEdit, let you remove some of the clutter; however, I have yet to see any GUI editor let you remove all of the clutter to the extent possible (or default) with Emacs or VI.
I bought a Tesla although I did look seriously at the Leaf. I also did some research on the upcoming BMW i3.
So far I've been amazed by the Tesla and in no way regret the decision to buy it. It's an incredible car.
The Leaf falls short on a number of fronts:
While the BMW i3 is not on the market yet, what i've read makes me believe that it will use very similar technology to the Leaf with the only real difference being the additional of an optional small gasoline engine. Yet more complexity, more weight, and more maintenance. Exactly what I do not want to see in an EV.
If Nissan wants to compete with Tesla they're going to have to change both their mindset as well as the mindset of their dealers. I would argue that an electric car is not just a gasoline car with the gasoline engine and gas tank replaced with an electric motor + batteries. It really is a different type of vehicle that requires rethinking what a car should be from the ground up. Until Nissan, Ford, GM, etc., as well as the car dealers, figure this out, they'll be unable to compete on equal terms with Tesla in the EV market.
I also recently purchased one of these MacBooks and am running Linux on it via VMWare Fusion. I really love the hardware (not thrilled with OS-X however). I am running Scientific Linux with the KDE Trinity desktop. Works really well although I did have to adjust the font sizes and use the larger icon sizes to make it comfortable to use.
Thanks to the heavy hand and morally bankrupt behavior of the RIAA and much of the music industry, I abandoned new music all together. I simply stopped listening to it, even on the radio. I have a reasonable collection of CDs from prior to the year 2000 that I still enjoy. nI want to see the RIAA, Sony, and all the other creeps in the industry go out of business !
I don't download music off the Internet and I don't borrow CDs from anyone outside of the family. When the music industry stops lobbying to destroy our freedoms, and starts treating both their customers and the musicians with some respect I'll again start purchasing music again. Until then, the industry won't get a dime from me nor any attention. .
It will depend heavily on what path your students pursue.
I've done a mixture of hardware design and firmware development for both storage peripheral companies and IC houses. What I mostly see is:
I have yet to see any significant use of Mac's, except as clients to log into Linux workstations. Almost all IC design and verification is done on some POSIX compliant OS because of the the requirements of the tools. IC houses I've worked for generally have large numbers of 32, 64, and 128 way multi-processor systems with huge amounts of RAM. Windows XP is simply not able to take full advantage of these large systems and the tools require this much horsepower to be effective. I also have noted that many IC designers generally seem to prefer the power of a good CLI over GUI point-in-click file managers. There is also a lot of scripting in these environments, mostly in Perl (although I've also need shell script and Python used). Linux and similar operating systems lend themselves more for this sort of work.
As for tools, I would suggest that you seriously look at trying to give your students at least a taste of such tools as MatLab, MathCAD, AutoCAD, and S. There are free equivalents for MatLab such as Scilab and Octave as well as Python packages such as SciPy, NumPy, and MatPlotLib (which I sometimes use for modeling). I know that languages such as S+ (or the free R language) are sometimes also used for statistical analysis. If you want to give your more advanced students a taste of chip design, consider the free offerings from Xilinx along with a few of their FPGA evaluation boards (available through DigiKey).
I hope this helps.
Unless your long time vegetarian or vegan, then steak truly is just disgusting.
Vegetarian for 8+ years - never once felt the desire to go back to eating warmed dead rotting animal carcass. The point is that what tastes and looks good is largely dependent on what you consider food.
Watching this video actually made me rather sad...
Even if you don't like Microsoft now, they were a great company once. Every company eventually fails. We're now witnessing the fall of one of the most successful in history.
I really hope this bloke does not have this database on a system connected to the Internet -- Especially a Windows machine !
First off, take a deep breath. I really don't want to argue and won't post further after this on this subject.
Relating to the initial conditions on the second and third, I did state at the top of my example that k>0 so the loops are functionally equivalent as far as they'll both calculate the same result for the same input.
Note that the differences in my original code was the loops. With that being said, I agree that what the compiler does inside the loop will vary and exactly how it constructs the loops may vary (I even say so and discuss in my comments). However, the number of tests and the space available for optimisation is limited in the three cases. This is inherent in how the loops are constructed. I would argue that, while the compilers may optimise differently, the structure of the loops constrains what the compilers can do (you'll also notice that the loop index does not impact the operation performed in the loop. This was by intent for the example). Again I allude to this in earlier posts.
To demonstrate the point, I took the first and third examples, encapsulated them in functions so that the compiler has limited information it can use to guess the constraints on j and k (although I did make them unsigned, I believe you'll find that the compilers would generate nearly identical code for signed integers) and compiled the code on several compilers:
- ARM RealView - THUMB2 instruction set
- ARM RealView - ARM instruction set
- GCC x86
In all cases, I dumped the generated assembly (using the -S switch which is common to all three compilers). I also ran the compiler using three optimisations: -O1, -02, and -O3. Instructions not related to routine entry or exit or to the j *= j++ operations have a prepended "*" (i.e. instructions used to construct the loop). I've tabulated the number of instructions associated with the looping constructs for all cases. For the THUMB2 instruction set, I also tabulated the time through each pass through the loop in clock cycles assuming no cache, zero wait-state RAM and a 3-stage instruction pipeline (which is very reasonable for these processors in an embedded system).
Here's the C code:
unsigned f1(unsigned j, unsigned k);
unsigned f3(unsigned j, unsigned k);
unsigned f1(unsigned j, unsigned k)
{
unsigned i;
for (i=0 ; i<k ; i++)
{
j *= j++;
}
return j;
}
unsigned f3(unsigned j, unsigned k)
{
unsigned i = k;
do
{
j *= j++ ; i--;
}
while (i);
return j;
}
Output for THUMB2, -O1:
||f1|| PROC
* MOVS r2,#0 ; i = 0
* B |L1.10| ; Jump to conditional test at end of loop.
|L1.4|
ADDS r3,r0,#1 ; j *= j++
MULS r0,r3,r0
* ADDS r2,r2,#1 ; i++
|L1.10|
* CMP r2,r1 ; Is i<k
* BCC |L1.4| ; Branch if less than
BX lr
I agree that I probably should have been a bit clearer in the examples, my mistake (I guess that's what I get for doing this at around 2:30 in the morning).
My intent was to give an example that would calculate (j+k)!/j! but I screwed up and the code actually calculates (j+k-1)!/j!. If j=1, you'll see that the code calculates k!.
What I was driving at was in how the compiler would tend to construct the loops (without apriori knowledge of the constraints on the integers j and k.).
In the first example, the test occurs prior to entering the loop and the comparison is against k. With most compilers, the resulting assembly code (written as a generic assembly language) would be something akin to:
move i,#0
jump test
loop:
multiply j,j,j
increment j
test:
increment i
compare i,k
branch_if_less_than loop
I have also seen compilers (such as some old Keil Franklin compilers) construct the loop differently so that it can place the test at the top, either doing the test twice or adding a jump at the bottom of the loop back to the test.
In the second example, the test occurs at the top but the comparison is against zero. This will often optimize the code above by removing the need for the compare instruction:
move i,k
jump test
loop:
multiply j,j,j
increment j
test:
decrement i
branch_if_not_zero loop
Note that this statement is not always universal. There are some processors that don't set flags on an inc/dec instructions and therefore still need the compare operation. Also, some processors, such as Z80 have a DJNZ instruction that combines the decrement and the branch if non-zero instruction into a single opcode.
Also note that the second example may also be able avoid the move instruction at the top if the value of k is not needed after this segment of code executes.
The third example removes the need for the jump instruction:
move i,k
loop:
multiply j,j,j
increment j
decrement i
branch_if_not_zero loop
Again, the compiler may be able to remove the move instruction at the top if it has no use for k after this code segment.
The 20% number I quoted was based on past experience with similar sorts of tight loops on ARM 9 and ARM Cortex-M3.
Relating to using the compiler as a macro language, I did not mean to imply that you ignore the abstraction that the high level language gives you (intent of my comment about maintainability), only that you write the code being very mindful of the output and optimise your source code to help the compiler optimise it's output, as I tried to show with the loops. This is never done in a vacuum, you both learn how the compiler does it's optimisation and also review what the compiler actually generates for those time critical sections of code that you really care about (typically by single stepping using an in circuit emulator, trace-port analyser or, in some cases, a simulator).
As a firmware/electrical (as opposed to software) engineer, I used to write in assembly language almost exclusively (on deeply embedded 8-bit microcontrollers with very limited resources. I still occassionally write some very time critical assembly code for 32-bit ARM processors). I can state for a fact that there is tremendous value in having a good understanding of and experience coding assembly languages, even today:
If you know assembly, you can much more easily understand the trade-offs between different, functionally identical, high level constructs. As a simple example, consider the follow three slighly contrived snippets of C code. In all three examples, k > 0:
for (i=0 ; i<k ; i++) j = j*(j++);
versus:
for (i=k ; i ; i--) j = j*(j++);
versus:
i = k ; do { j = j*(j++) ; i--; } while (i);
On most architectures, the first will generally be least efficient and the third will generally be most efficient (often by as much as 20%), why ?
There are a number of "tricks" that you learn after writing assembly that are useful when writing higher level languages. These "tricks" are almost never taught in school and are rarely seen in high level code. As an example, what's the fastest and most concise way to check if an integer is a power of 2 (for arbitrarily large integers) ? How about:
if (0 == ((i+1)^i)&i) { /* A power of 2 */ }
There are in fact a large number of tricks like this, a number of them can be derived by examining the basic boolean expressions that define binary addition (and subtraction) with carry.
While you can argue that an understanding of assembly is less valuable for application programmers because machines are "fast enough", there are certainly cases where shaving 20% off a tight loop can be noticeable to the user. Also, writing application programs is only one facet of the larger discipline of computer science/computer engineering. People that work with real-time systems or develop operating systems (especially on cost sensitive products), by necessity, do make use of these skills. Because of the push to always lower costs, processor resources on deeply embedded systems will generally always be sized to be just big enough and therefore niche needs for these skills will never disappear (at least it hasn't in the 29+ years I've been doing this sort of work).
Sorry, but based on my experience, I disagree with the point of this article.
I find both Gnome and KDE far more usable than the commercial offerings that are available. Specifically, I find the following features really useful:
These are features that I have yet to see on a widely used commercial offering out of the box and features that I find really boost my productivity. Yes, there are commercial add-ons (such as StarDock), but they're buggy as all get out and generally suck compared to what I can get on a standard Linux install. One feature that generally makes me tend towards KDE over Gnome is the ability to place the taskbar on the side of the screen instead of the bottom and still have something that is very usable. When you write lots of code, you want more height, not width. Wide screens are great for multimedia but are generally poor for code development. For coders, placing the taskbar on the bottom makes less efficient use of the screen.
Relating to innovation, the FOSS movement has certainly been the source for lots of innovation. This "lack of innovation" seems to be a recent mantra being thrown out against the FOSS movement. Consider:
Sorry to burst the article's bubble, but FOSS has been the source for a huge amount of innovation. What I see coming from the commercial offerings has been, to a large extent, an apeing or imitation of ideas started by the FOSS movement with some incremental improvement on the original idea.
Heartily agree. Talk (at least on VMS) was a great little app.
Within days of Word 97 coming out on the market, I attempted to print a document with a footer containing the page number and number of pages. Word 97 would screw up the page count the first time it would print a document so pages with page number of the form 1 of N, 2 of N, etc. would come out as 1 of 1, 2 of 2, etc.
I contacted MS through my company's support contract to find out that they were aware it was broken and their solution was that I should not use this feature. I continued to use the feature but always printed to a file prior to printing for real to get the page count correct.
Asked if they were going to supply a patch. Received a simple No, Asked if they would fix it in the next release, the person on the phone again indicated simply that they had no plan to fix it.
Several weeks later I called asking if there was anything that could be done to keep the equation editor from crashing when I used it. I received the exact same set of answers.
So much for support.
Lots of anti-party sentiment on /. and for good reason. Question is, as law abiding citizens of the US (and other countries with similar problems), what do we do to solve the problem.
It's easy to gripe but griping does no good. May I suggest that we start looking for a solution rather than just complaining about the problem.
The solution to treaties like the ACTA as well as laws like the DMCA is simple:
The only way to stop the stupidity is to pull the rug out from under the corporations and organizations that support this stupidity in the first place, both financially and legally.
Besides, how many songs or recent movies are worth the plastic they're distributed on anyway ?
To AcidPenguin9873: You're comment is really on a larger subject than treaties like the ACTA and DMCA. You're right that western cultures are moving towards an information based economy. A big part of the problem is that the existing laws help the large players in the entertainment industry but cripple smaller players and also cripple other industries. Therefore, these treaties and laws are really not beneficial to our society as a whole. The laws also marginalize existing rights under copyright: first sale rights and fair use rights, both of which are important to allow commerce on used material continue and to allow commentary, satire and, in some cases, innovation.
Why: For the most part, at least in engineering and also to a somewhat lesser extent in entertainment, every new idea (or song, or movie plot) is simply a rehashing of existing ideas with some new wrinkle or improvement. Innovation is almost always incremental, not revolutionary. I have seen this over and over at multiple employers over my 30 year career (I used to work in professional audio, I now work in data storage).
For one product I worked on, legal pared down the number of possibly infringing patents to over 60,000 which a team of 20 of us spent months reviewing over evenings and weekends while also working on product development. Of that 60,000, roughly 100 actually overlapped what we were working on in some way and caused us to find ways to work around them or cross-license them.
Question: What happens when this number of patents (or trademarks, copyrights) increases 100 fold ?
Question: How will smaller players and start-ups ever be able to compete if they must cross-license with a larger player that does not want them in the market ? The chance of this occuring increases with the number of companies that the small player must negotiate with which also increases with the number of overlapping patents.
Question: Given how the laws are going and if the number of patents, and/or copyright increases substantially (which will happen in an information society), how can smaller players with limited cash flow successfully compete with larger players with much greater cash flow.
Point is that, should such a society develop with the laws moving in the direction they're moving (and assuming their fully enforced):
While protection of ideas and content is important for