• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

How much electricity would be saved worldwide if Windows was writen in Assembly?

Status
Not open for further replies.
Hi,
I was just wondering if it is possible to guesstimate a number for this question. :\
I chose the CPU forum because I thought it comes down to work being done by processors.

I really should close this abomination of a thread. But instead I'm going to move it to the Programming forum.

-ViRGE


Well, gee, thanks!

Markbnj
Programming moderator


If ever a thread has run its course, this one has. Feel free to take the optimization discussion to another thread or start a new one.

Markbnj
Programming moderator
 
Last edited by a moderator:
0

because the world is fueled by greed.

And greed states having more then what you need.

BTW welcome to AT.
 
0

because the world is fueled by greed.

And greed states having more then what you need.

BTW welcome to AT.

Thanks for your warm welcome.

We talk about energy conscious hardware all the time. I thought it is about time to consider software as well. Would the savings justify paying more for the extra time?
 
Last edited:
The question implies that MS could write (or rewrite) all their current, available versions of Windows in ASM. Could they? Win7 (and Vista) suffered enough delays as it is . . . can you imagine how slow their releases would be if they had to write the whole shebang in ASM?

In a best-case scenario, they'd release cut-down operating systems with as much functionality as possible with as few bells-and-whistles as possible. People would flock to other platforms for eye candy and/or a more appealing UI, but geeks would probably love it. Of course, that would imply that "other platforms" even existed that could take the place of Windows. Switching to OS X or Linux requires certain . . . sacrifices.
 
I'll say 0 simply because the sheer amount of Time/Effort to Code Windows in Assembly would just likely Front Load the Consumption. It probably also would mean that we'd still be using something between Windows 3.1 and Windows 95.
 
Modern compilers are extremely efficient and probably do a better job than most programmers would in assembly. Windows is far too large to do in assembly. Part of the reason why GUI's weren't prevalent until the 90's is because of a lack of good compilers.

Assembly doesn't equal efficiency, assembly just means the programmer does almost 100% of the work.
 
I'll say 0 simply because the sheer amount of Time/Effort to Code Windows in Assembly would just likely Front Load the Consumption. It probably also would mean that we'd still be using something between Windows 3.1 and Windows 95.

Suppose Microsoft employs 100 programmers to translate their c code into assembly and pays them each 5000 Dollars a month. That makes 500000 Dollars a month. That's peanuts for MS.
Now, when an application with c code processes 1000 000 000 instructiions to complete, and with assembly code does the work with much less than half that instruction count, there is going to be some energy saving. Multiply that by the number of computers worldwide and it has to add up to somthing. So saying "0 power savings" is incorrect. With new processors whitch shut down complete cores at idle, I think we are talking about considerable energy savings, which exceed the 500000 dollars overhead.
 
Suppose Microsoft employs 100 programmers to translate their c code into assembly and pays them each 5000 Dollars a month. That makes 500000 Dollars a month. That's peanuts for MS.
Now, when an application with c code processes 1000 000 000 instructiions to complete, and with assembly code does the work with much less than half that instruction count, there is going to be some energy saving. Multiply that by the number of computers worldwide and it has to add up to somthing. So saying "0 power savings" is incorrect. With new processors whitch shut down complete cores at idle, I think we are talking about considerable energy savings, which exceed the 500000 dollars overhead.

Maybe 20 years ago compilers were that inefficient, but it's simply not the case today. It's not really possible to write programs as big as Windows in Assembly.

Have you ever actually used it yourself?
 
Debugging something that large in assembly would be impossible. Seriously I had trouble debugging my 150 line assembly program I cant imagine what something a few billion lines long would be like.
 
Modern compilers are extremely efficient and probably do a better job than most programmers would in assembly. Windows is far too large to do in assembly. Part of the reason why GUI's weren't prevalent until the 90's is because of a lack of good compilers.

Assembly doesn't equal efficiency, assembly just means the programmer does almost 100% of the work.

I am afraid I have to disagree. No compiler can come anywhere close to assembly code. I think the reason high level languages took over was the lack of energy awareness and the relatively small number of computers worldwide. Now that this awareness is there and computers consume huge amounts of energy, a return to assmbly COULD be worthwhile.
Note that I am not saying it IS worthwhile. I just think it is worth a calculation.
 
Suppose Microsoft employs 100 programmers to translate their c code into assembly and pays them each 5000 Dollars a month. That makes 500000 Dollars a month. That's peanuts for MS.
Now, when an application with c code processes 1000 000 000 instructiions to complete, and with assembly code does the work with much less than half that instruction count, there is going to be some energy saving. Multiply that by the number of computers worldwide and it has to add up to somthing. So saying "0 power savings" is incorrect. With new processors whitch shut down complete cores at idle, I think we are talking about considerable energy savings, which exceed the 500000 dollars overhead.

...and how many Months will it take for the 100 to make the Conversion? It's really not a matter of Conversion either, 1 simple Command in C will break down into, damn my head hurts just thinking about it, who knows how many Assembly Commands.

Debugging is probably going to take longer than the actual Coding. Since you've greatly increased the possibility of Error.(oops, see Dark4ng3l beat me to this)

New Hardware features would take Years to be implemented.

I see no advantage to doing this.
 
Debugging something that large in assembly would be impossible. Seriously I had trouble debugging my 150 line assembly program I cant imagine what something a few billion lines long would be like.

Debugging assmbly code is as difficult as any other code if you are used to it. I am not expecting MS to switch to assmbly overnight. They can start by re-coding the most important files and gradually move to the rest of the OS.
 
Debugging assmbly code is as difficult as any other code if you are used to it. I am not expecting MS to switch to assmbly overnight. They can start by re-coding the most important files and gradually move to the rest of the OS.

This is good, because I suspect the thought won't even come across their minds.
 
...and how many Months will it take for the 100 to make the Conversion? It's really not a matter of Conversion either, 1 simple Command in C will break down into, damn my head hurts just thinking about it, who knows how many Assembly Commands.

Debugging is probably going to take longer than the actual Coding. Since you've greatly increased the possibility of Error.(oops, see Dark4ng3l beat me to this)

New Hardware features would take Years to be implemented.

I see no advantage to doing this.

YES. it does take longer to code in assembly. a possibility would be to write the code in c as usual and after debugging pass it on to an assmbly programmer for optimization. Costs more. but again would the energy savings justify it?
 
YES. it does take longer to code in assembly. a possibility would be to write the code in c as usual and after debugging pass it on to an assmbly programmer for optimization. Costs more. but again would the energy savings justify it?

What Energy Savings? This point hasn't even been shown yet.
 
I am afraid I have to disagree. No compiler can come anywhere close to assembly code. I think the reason high level languages took over was the lack of energy awareness and the relatively small number of computers worldwide. Now that this awareness is there and computers consume huge amounts of energy, a return to assmbly COULD be worthwhile.
Note that I am not saying it IS worthwhile. I just think it is worth a calculation.

That's simply not true at all. C compilers are extremely efficient.

You also have to remember, assembly is typically used for simple tasks and programs for the most part. Those programs are small enough that they can be tweaked to oblivion to be efficient by a human.

When you start getting into complex programs (OS sized), it would be impossible for a human to extract the same amount of performance on that scale with assembly.

Assembly does not equal efficiency!! Assembly just has an interpreter between the programmer and machine language rather than a full compiler. Keep in mind often the best tier programmers write the compilers. That enables even bad programmers to write fairly efficient programs.

Writing Windows in Assembly would take a monumental amount of time. All the time would be spent just writing the basic kernel, there'd be no time to add in power saving features or routines which are a part of Windows today thanks to being written in higher level languages.

Again just to emphasize, assembly does not equal efficiency. Assembly is simply the closest you can get to writing in machine language without using HEX or binary.

I suppose you can liken it to the Cortex A8 CPU and the A8 residing in the Apple A4. The A4's cortex can be clocked higher because it's layout was tweaked manually vs. the regular A8 which was laid out by programs. However, look at how much later that A4 CPU came out vs. the Cortex A8 (more than a year later). Essentially by the time it came out, A9 CPU's are almost upon us and not to mention Snapdragons which are also about as fast.


I have to ask, are you actually a programmer? You really do not seem to know what you are talking about since you seem to assume that Assembly equals instant efficiency.
 
snipped for...efficiency! 😀

You pretty much nailed it IMO. Going by the OP's apparent Thought Process, he/she should cut out the "inefficient" Assembly and be suggesting Machine Code for this purpose. What could possibly be more "efficient" than the actual Code the Hardware uses?
 
That's simply not true at all. C compilers are extremely efficient.

You also have to remember, assembly is typically used for simple tasks and programs for the most part. Those programs are small enough that they can be tweaked to oblivion to be efficient by a human.

When you start getting into complex programs (OS sized), it would be impossible for a human to extract the same amount of performance on that scale with assembly.

Assembly does not equal efficiency!! Assembly just has an interpreter between the programmer and machine language rather than a full compiler. Keep in mind often the best tier programmers write the compilers. That enables even bad programmers to write fairly efficient programs.

Writing Windows in Assembly would take a monumental amount of time. All the time would be spent just writing the basic kernel, there'd be no time to add in power saving features or routines which are a part of Windows today thanks to being written in higher level languages.

Again just to emphasize, assembly does not equal efficiency. Assembly is simply the closest you can get to writing in machine language without using HEX or binary.

I suppose you can liken it to the Cortex A8 CPU and the A8 residing in the Apple A4. The A4's cortex can be clocked higher because it's layout was tweaked manually vs. the regular A8 which was laid out by programs. However, look at how much later that A4 CPU came out vs. the Cortex A8 (more than a year later). Essentially by the time it came out, A9 CPU's are almost upon us and not to mention Snapdragons which are also about as fast.


I have to ask, are you actually a programmer? You really do not seem to know what you are talking about since you seem to assume that Assembly equals instant efficiency.

I have to disappoint you. I know too well what I am talking about. I disassembled some programs written in c and I was shocked at the number of useless instructions and how inefficfient the loops were. Assembly DOES mean efficiency.
 
So 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. 😱
 
I have to disappoint you. I know too well what I am talking about. I disassembled some programs written in c and I was shocked at the number of useless instructions and how inefficfient the loops were. Assembly DOES mean efficiency.

You sure about this? An OS is rather dynamic, sometimes those "useless instructions" might actually be vital for proper operation. IOWs, you sure those Instructions are not there to address occasional Variables?

I can possibly see a situation where a Programmer uses a Command that does more than he/she Needs, but is that the fault of the Language or simply a poor choice by the Programmer? If it's the Language, perhaps the Language simply needs a new Command.
 
So 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. 😱

Ya, but you start with an Assumption. Much like your OP. Assumptions are great to get the result you want, but not so great at coming to a good or practical Conclusion.
 
Status
Not open for further replies.
Back
Top