Now you are being unfair again. Some people started insulting. including yourself. I dont mind being countered. that is what forums are for. but some objectivity is also required.
- Status
Now you are being unfair again. Some people started insulting. including yourself. I dont mind being countered. that is what forums are for. but some objectivity is also required.
i wasn't arguing that your well crafted asm was not faster than the windows c++. but good C++ compiled, vs good asm, is not going to be a huge difference.
inefficient code is going to be terrible in general.
i used to work for a big AV vendor for the consumer division. i remember once a decision was made to have an animated globe during scans that would spin while it waws scanning. to animate the globe the devs who were well apparently retarded put the code to animate in the main thread...
anyhow this made the scan about 20% slower. since it was close to the ship date and they didnt wnat to have to fix everything, all that was done was it was changed into a stock progress bar instead of an animated globe... it only was 5% slower, but still.
bad code is goin gto be slow. good code, compiled with a good compiler, vs. asm is a totally different story.
inefficient code is going to be terrible in general.
i used to work for a big AV vendor for the consumer division. i remember once a decision was made to have an animated globe during scans that would spin while it waws scanning. to animate the globe the devs who were well apparently retarded put the code to animate in the main thread...
anyhow this made the scan about 20% slower. since it was close to the ship date and they didnt wnat to have to fix everything, all that was done was it was changed into a stock progress bar instead of an animated globe... it only was 5% slower, but still.
bad code is goin gto be slow. good code, compiled with a good compiler, vs. asm is a totally different story.
compilers are so good at optimizing now, and C++ is so efficient, that there's really no point.
Besides, the extra gas spent by all the new employees driving back and forth to recode windows to assembly would far outweigh any negligible energy savings.
the difference is more often than not, depending on the function of the code quite substantial. Gains of 100 fold are not rare. I should know, I do it. Compilers are not nearly good enough and they NEVER will be. Let's put it this way, Crisis with optimized asm code would run ok on a netburst cpu.
Hacp
Lifer
- Jun 8, 2005
- 13,923
- 2
- 81
How much energy would be saved if we didn't use computers at all? Just do that math mentally. Its the most energy efficient way.
Now getting back to reality; environmental wackos aren't welcome here. Go back to eating your organic carrots while I enjoy my steak. I can waste as much energy as I want thank you. I have all the lights turned on and the AC at full blast 60F. Nananana na na, you can't stop me!
Schmide
Diamond Member
- Mar 7, 2002
- 5,751
- 1,042
- 126
I'm pretty sure its immeasurable. The things an OS does, especially after boot, a few cycles here and there are not really going to make any accountable difference. PSUs are inherently inefficient at lower power and at some point lower power really doesn't matter.
I like to think of it as when you're driving your car and you turn on the heat or radio, it really doesn't make that much if any difference. Some things are just byproducts.
code65536
Golden Member
- Mar 7, 2006
- 1,006
- 0
- 76
Okay, let's have some fun...
1) Windows is written in C (with a little C++ for newer components, and .NET for some of the newer applets). Since C is really nothing more than a more readable (and portable) version of assembly, C is inherently easy to convert into efficient machine code because C is designed to be a very low-level language that easily and clearly maps to machine code. Microsoft's C compilers are very efficient. Very few people can hand-code more efficiently than their compiler (there may be places where, yes, I can do better, but there are also situations where it comes up with a way of coding something that I would not have thought of), and even if I do go in and hand-optimize their code, the benefit would be so small as to be virtually immeasurable.
2) You know, there is a thing called portability and feasibility. And the reason why people insult you is because people who have actually programmed will tell you gaining a few clock cycles is not worth the vastly increased tedium and difficulty. Not to mention the loss of portability. Windows can run on x86, x86-64, Alpha, PowerPC, and IA-64. All thanks to C.
3) As mentioned before, most of the time, the OS is sitting there idling. Optimizing a tight loop that iterates a few billion times makes a difference, yes. Optimizing an instruction that's run maybe a few thousand times total is pointless.
4) Programmer competence and algorithm choice is far more important than whether or not you use a compiler. Someone who uses a C-style instead of a Pascal-style string for text that is constantly being concatenated is going to cause a lot more inefficiency than a compiler. Now, many programmers use the wrong type of string or wrong form of memory allocation because that's just what their library uses, but that's not the fault of the compiler (even if the library is, say, the standard C library): that's the fault of the programmer for not recognizing the performance limitations and characteristics of what they're using.
Point is, this whole thing about compilers is tilting windmills: first, it demonstrates a lack of understanding of what exactly the role of the compiler is (and thus just how very little modern compilers contribute to inefficiency), and second, it's not even the target that you should be looking at.
Let's put it this way: Crysis would not even exist if people tried to hand-code it without a compiler.
And to answer your question: immeasurably small, because the amount saved would be drowned out by background noise.
Last edited:
It is more than a few cycles here and there. Now let's suppose we optimize an API which is heavily used by the system and take only ONE instruction out of a loop, That loop is going to run millions of iteration if not billions, a day. multiply that by the number of days that code is going to be used. It is normally years. again multiply that by the number of computers world wide, and you get a saving which is well worth the effort.
taltamir
Lifer
- Mar 21, 2004
- 13,576
- 6
- 76
1. If MS was writing windows in assembly, it wouldn't be popular (due to lack of features) and people will use something else, no change there. Assembly = Nobody use it.
2. If forced to program in assembly, programmers are not automatically creating better code. The compiler can create better code then a programmer if the compiler has been optimized for efficiency, and the programmer doesn't know every little thing about coding efficient code. So, Assembly =! better code.
3. If forced to write it in assembly, MS would be too busy implementing basic features to get around to program all those nice power saving features they have created. As a result PCs would be less efficient, since they would be lacking the power saving features they currently have. So, Assembly = Less power saving features.
This all combines to:
If MS wrote windows in assembly, worldwide power consumption would go up, not down.
2. If forced to program in assembly, programmers are not automatically creating better code. The compiler can create better code then a programmer if the compiler has been optimized for efficiency, and the programmer doesn't know every little thing about coding efficient code. So, Assembly =! better code.
3. If forced to write it in assembly, MS would be too busy implementing basic features to get around to program all those nice power saving features they have created. As a result PCs would be less efficient, since they would be lacking the power saving features they currently have. So, Assembly = Less power saving features.
This all combines to:
If MS wrote windows in assembly, worldwide power consumption would go up, not down.
MS could continue as usual, but also employ some opimizers, who work on finished code and shave off clock cycles here and there.
Again I should emphasize I know exactly what I am talking about. For example the Windows string concatenation API takes an order of magnitude more clock cycles than the one I have written in asm. It is just one example. Windows has grown so big that it needs to be optimized, otherwise it has no future.
Perhaps they do. Only Microsoft people would know for sure. If the Linux people do it (implementing parts of the code in assembly when needed), I'm sure it is something that Microsoft has already evaluated.
For any real number (the original point of your thread) to be derived properly, we need a project as big as a modern OS to be done in assembly, and see if it is even feasible.
Small things can be done easily. And doing many many small things is likewise easy, just time consuming. But doing small things that are integrated to each other forming one bigger whole is something else. That is why doing small, stand-alone "office automation systems" per department is easy. Ten of them is also easy enough to do. But if they are actually parts of a whole, it becomes more complicated. And so ERP-type systems are hard to implement, and why managers/executives don't see why. They just believe it is just 10 or 20 of the small systems joined together, so it should be no more than 10 - 20x more difficult and complex than an individual stand-alone system in a department. Reality is that any time elements/entities/components have to interact with other elements/entities/components, complexity shoots up beyond linear. I found DrMrLordX's reference to the Mythical Man Month very apt, I was not aware he was a programmer himself.
Not to make a conclusion to a problem/test I proposed myself (having a modern OS done in assembly), but there's a reason for having higher-level languages, and it is not because of this:
Programming languages are tools, and nobody makes tools "just because". The old tools had room for improvement, and so they did improve, and we have what we have now. Saying that programming languages only developed into higher-level ones due to "lack of energy awareness" is just flat out wrong. Tools evolve as needed, and that's exactly what happened with programming languages as well.
I guess in summary, what I'm saying is basically two things:
1.) Making a huge, complicated program like an OS entirely in assembly is not feasible (not to mention, non-portable, which is very important for operating systems like Linux and friends)
2.) As for continuing as they are now, but employ optimizers... the Microsoft campus is filled with incredibly smart people. I am sure they have had hundreds of discussions about optimization techniques; I don't think they missed the one idea about putting in assembly code in high-traffic areas of code.
I enjoyed the discussion here, however. It is something to think about, but in the end, assembly is too low-level, non-portable, and much much harder to maintain and extend.
My two cents, at least.
How can they have no future? You started the thread on a reasonable point of discussion. But now, you took a sharp turn stating unless it does things your way it will have no future. I am now confused and do not know if you are serious or you are stringing us along for your amusement.
taltamir
Lifer
- Mar 21, 2004
- 13,576
- 6
- 76
MS already does that... Certain specific part of windows are written in various languages, some even in assembly.
1. does it have a significant impact on performance?
2. does your API perform all the various features their's does?
3. Is it backwards compatible with software build for older windows versions?
Bashing programming tools as inefficient is like bashing the http://en.wikipedia.org/wiki/Threshing_machine
A human can thresh by hand, picking out individual grains, and make sure that 100% of all grains are properly threshed and collected.. it will take an inordinate amount of time (which is why manual threshing just attempts to reach "acceptable" levels of threshing... actually, so does mechanical). A tool that can massively simplify the work and massive increase the creativity of each person is a necessary AND awesome. I never understood the fascination with assembly, yea, you can make tighter code, but that doesn't make it better... usually its quite a bit worse because you have to spend inordinate amount of man power, and have very little return to show for it.
Last edited:
of course it has an impact on performance. suppose you are looking for a certain string somewhere on your computer. Every byte on your computer is running through various loops. optimizing those loops is almost hoily for an OS.
Yes. my procedure does everything windows API does and more. Mine even returns some more values which could be useful for further savings.
It is compatible all the way.
By the way, I am just a third class ( or even less ) programmer, I am sure professionals could do much better than that.
Murloc
Diamond Member
- Jun 24, 2008
- 5,382
- 65
- 91
peanutsSo I tried to figure it out unscientifically. If each computer uses 1 Cent less energy a month, and we have a billion computers laptops and so on, we get a saving of 10 000 000 Dollars.
Not my way young man. Right way. Technology has by the way of it's nature a tendancy to expand and improve, it must move on otherwise it will die. Windows has now so many features that it is hard to further expand it. a few useless things here and there, and that is it. Starting to optimize code could be a nice kickstart in a new old era.
It is against my better judgement to continue participating in this thread, but here goes my last shot:
The fact that MS uses C, C++ and .NET on Windows is what enables it to have all these features (which are a good thing) and make these features maintainable AND extensible. I do not know what else there is to say.
"The Right Way", as you call it, will only have an impact if Windows is unbearably slow on current hardware. It is not.
In other words, there is no problem existing now that is curable by assembly that, left "un-cured", will make Microsoft Windows die.
I have never seen more fail in a thread or in an OP.
You have never worked in development have you? Let me guess, second year university/college student?
No, MS cant spare that much money for a pointless exercise. Which is more expensive - electricity of programmers? Programmers, by far. To add to that, the amount of human effort needed to rewrite Windows 7 in assembler would probably be the region of a million man hours plus. Probably way more than that. The sheer effort in writing it, and the resources, natural and otherwise, wasted while doing it, would outweigh the potential energy savings.
Which, lets not forget, wont be as great as you think. I'm 99% certain that some mission critical parts of Windows are written in assembler, the ones that need to be as fast as possible. Parts of the kernel, for instance.
You have never worked in development have you? Let me guess, second year university/college student?
No, MS cant spare that much money for a pointless exercise. Which is more expensive - electricity of programmers? Programmers, by far. To add to that, the amount of human effort needed to rewrite Windows 7 in assembler would probably be the region of a million man hours plus. Probably way more than that. The sheer effort in writing it, and the resources, natural and otherwise, wasted while doing it, would outweigh the potential energy savings.
Which, lets not forget, wont be as great as you think. I'm 99% certain that some mission critical parts of Windows are written in assembler, the ones that need to be as fast as possible. Parts of the kernel, for instance.
suppose windows 8 is twice as fast as windows 7. and uses half the power accordig to benchmarks you read on the net. you are going to willingly buy it, even if you don't need the extra speed and you don't care about the few saved watts. just like when sandy bridge comes along and is twice as fast as your core2. you don't need it. but you'll be at least tempted to buy it. your core2 doesn't have a problem. but you are still likely to buy the new one. that is what keeps the industry going.
Going for "faster" only continues until "good enough" is achieved. General performance of the OS is now bottlenecked by the platter-based drive. The cure is an SSD. Performance, as I can see it, is and has been good enough for quite a while.
And Windows 8 (assumed to be the "all done in assembly" version) won't be 2x as fast. It's likely not even feasible at all to accomplish.
It is hard to say "thread derailment" seeing as to how you are the OP, but you are wrong and you are derailing your own thread. Your original topic was atleast a good mental exercise for a while, but now talking about a 100% speed improvement or whatever else overstating the benefit of implementing purely in assembly while keeping a blind eye on all other related issues (feasibility, maintainability and extensibility nightmares, project management and development of large-scale, complex systems as opposed to just small individual components).
EDIT:
As a mental exercise, let's say we live in a world where implementing in pure assembly is just as fast and easy as any other high-level language. In this case, yes, there would probably be significant electricity savings.
That's the fantasy world of course. Higher-level languages developed due to the need to be more productive.
So in the real world, acquiring the "theoretical pure-assembly derived electricity savings" is not feasible. Modern OSes (and likewise, all other large-scale, complex systems like ERPs, office suites, Photoshop and derivatives, etc) have been made possible due to having better tools, which are the higher-level languages. Saying "we should just go do them in assembly" and "higher-level languages were because of lack of energy awareness" assumes the scenario in fantasy land, whereas the reality is the improved tools were a necessity to begin with.
And Windows 8 (assumed to be the "all done in assembly" version) won't be 2x as fast. It's likely not even feasible at all to accomplish.
It is hard to say "thread derailment" seeing as to how you are the OP, but you are wrong and you are derailing your own thread. Your original topic was atleast a good mental exercise for a while, but now talking about a 100% speed improvement or whatever else overstating the benefit of implementing purely in assembly while keeping a blind eye on all other related issues (feasibility, maintainability and extensibility nightmares, project management and development of large-scale, complex systems as opposed to just small individual components).
EDIT:
As a mental exercise, let's say we live in a world where implementing in pure assembly is just as fast and easy as any other high-level language. In this case, yes, there would probably be significant electricity savings.
That's the fantasy world of course. Higher-level languages developed due to the need to be more productive.
So in the real world, acquiring the "theoretical pure-assembly derived electricity savings" is not feasible. Modern OSes (and likewise, all other large-scale, complex systems like ERPs, office suites, Photoshop and derivatives, etc) have been made possible due to having better tools, which are the higher-level languages. Saying "we should just go do them in assembly" and "higher-level languages were because of lack of energy awareness" assumes the scenario in fantasy land, whereas the reality is the improved tools were a necessity to begin with.
Last edited:
100 percent improvement is an understatement. Again the entire OS doesn't need to be optimized. Just the important parts of it. And they are definitely not optimized. Again my selfish sounding phrase: "I know" because I have benchmarked them.
You're accusing the entire Windows developmen team of incompetence? Wow, naive AND arrogant.
Using assembler is all well and good until you have to delay Win7 until 2020 so that you can optimize it properly. And then you find that a prima donna has used that new Intel instruction not supported by AMD, so anyone running an AMD machine gets a hard crash. So you try to debug, only thats so much harder than doing so in C/C++/C#, so that adds 2 weeks to your development time.
Really, theres a reason people dont use assembler for large projects. Until you have worked in dev, and you obviously havent, you just wouldnt have a clue. Its nice to want to improve the world, but really, this just isnt feasible or even a good idea.
- Status
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter