GungnirSniper writes:
"UCLA engineers have found a way to use spin waves in multiferroic material to greatly limit electron leaks in processors. CrazyEngineers.com has a light read on the topic and links to the abstract of the paper with diagrams. This could lead to significant efficiency improvements in processor power use."
This discussion has been archived.
No new comments can be posted.
Multiferroics Improve Processor Efficiency - UCLA
|
Log In/Create an Account
| Top
| 1000 moderator points
| 23 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:17PM
I peed in my own butt! Tee hee hee hee!!!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:33PM
I peed in my own butt! Tee hee hee hee!!!!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:39PM
I peed in my own butt! Tee hee hee hee!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:40PM
I peed in my own butt! Tee hee hee hee!!!!!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:44PM
I peed in my own butt! Tee hee hee hee!!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:45PM
I peed in my own butt! Tee hee hee hee hee!!!
(Score: -1, Troll) by ngarrang on Friday March 07 2014, @05:47PM
...this is like an electronic version of adult diapers?
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:51PM
I peed in my own butt! Tee hee hee hee hee!!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:52PM
I peed in my own butt! Tee hee hee hee!!!!!!
(Score: 3, Funny) by fishybell on Friday March 07 2014, @05:54PM
I see we've achieved the /. level of discourse.
(Score: 4, Insightful) by ikanreed on Friday March 07 2014, @06:19PM
You have sucessfully changed your comment threshold. Phew, that were tough.
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:57PM
I peed in my own butt! Tee hee hee hee!!!!!!!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @05:59PM
I peed in my own butt! Tee hee hee hee!!!.!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @06:02PM
I peed in my own butt! Tee hee hee hee!!!!!!.!
(Score: -1, Troll) by Anonymous Coward on Friday March 07 2014, @06:07PM
I peed in my own butt! Tee hee hee hee!!.!
(Score: -1, Offtopic) by MichaelDavidCrawford on Friday March 07 2014, @06:45PM
I assert that quite significant energy savings can be achieved through no other means than refactoring the code we already have.
Some of my colleagues at Kuro5hin [kuro5hin.org]view me in the same light as a 9/11 Truther when I make this claim. But I am a Physicist; energy, work, force and power are fundamental to all of Physics while no University I am aware of has the requirement for Computer Science students to study Physics.
I am quite furiously angry that few if any Computer Science instructors ever consider the effect of modern computer architecture when discussing Algorithm Analyis. They simply assume that all addressable memory is resident rather than paged out to backing store, and they make no consideration of data or code caching, which in most of todays boxen is three layers deep.
There was at one time - a long time ago - a system call in SunOS - not Solaris - that I expect it inherited from BSD, that was intended to prepare the kernel for upcoming operations on the backing store. I don't clearly recall but I think it may have been "vmadvise()". I checked just now and find no man page for it on OS X.
One could inform the UNIX kernel ahead of time that one was about to address a lot of memory either in a generally linear or in a generally random fashion.
While the system call itself was present, it had no effect. I expect the original developers intended to use its advice to improve BSD UNIX' virtual memory algorithms but either could not find a way to make a real difference, could not obtain managerial buy-in for it or perhaps just never got to it.
However, if in your client code you know ahead of time how you will be addressing memory, there is a great deal you can do. For example you can cut down on memory bus traffic by avoiding cache loads and stores.
For example, say you want to write just one byte to a particular address:
char *ptr;
*ptr = 'X';
If the cache line that included the address that ptr held was not already loaded, the memory controller has no way of knowing ahead of time whether you plan to overwrite the entire cache line before that cache line must be written back to core.
So it will read in an entire cache line, it might well have to write out to core what had previously occupied that line, your code overwrites just one byte.
If you really do not read nor write that entire line, then the CPU did the right thing. But what if you later overwrite the rest of the bytes in the line's address range? You read a bunch of data that you immediately overwrote. That read was in reality completely unnecessary!
Most modern Instruction Set Architectures have ways of dealing with these, but they are all quite different from each other, I expect due to hardware patents.
Both POWER and PowerPC have machine instructions that clears a cache line to zero without reading the core.
The fancier ARM cores such as the Cortex A8 can be instructed to start loading the second-layer cache ahead of time. One does not have to get this right, the ARM takes care of cache coherency for you. GCC has a command line option to do this everywhere you're going to be looping over a buffer, but preloading the cache everywhere like that doesn't turn out to help. One must either use a profiler, or as I have over time, to develop an intuition as to what's really important and what is not, then to preload just some of the buffers with intrinsics.
The more-capable x86 and x86_64 CPUs can be informed ahead of time that one intends to completely overwrite an entire cache line. However you must get this write or you will corrupt your data!
Those who are heavily into runtime optimization, like graphic and network driver coders know all about this stuff.
But what no one other than myself seems to ever clue into is that it costs energy to do all those reads and subsequent writes. It makes your CPU produce more heat than would otherwise be the case, it needs a better cooling fan and a bigger, more expensive heatsink, the fan draws more current, your memory uses more power and gets hotter as does your power supply.
My friend Luke Crawford (no direct relation) tells me that power is his Xen VM and colocation service's [prgmr.com] biggest cost center. When one colocates with Luke, the price one pays for one's monthly colocation is determined largely by how much power one's server consumes.
It's not so much that Luke has to pay for the power your server consumes directly, but he has to pay I think Hurricane Electric to cover Hurricane Electric's costs of keeping its data center cool so every solder joint in the facility doesn't just fucking melt.
What I just said about preloading a cache line because you might not overwrite it all, also applies to backing store pages as while as to file and mapped memory writes.
I expect one would achieve the greatest by carefully reordering one's writes so that if one possibly can, if one writes into a kernel page cache page in any way, one writes into the whole thing all in one shot, with a single write() system call.
Anyone who works on drivers for I/O that is done in units of pages has to provide "Bounce Buffers". Suppose you write a megabyte to a file. If your write starts at the very beginning of the file, or rather the beginning of your write is aligned to any one page boundary, that write will be quick, efficient, it will use fewer kernel sources, it will thrash both the code and data cache less, it will use less electric power and Hurricane Electric won't need to blow so many samoleons on roof-mounted industrial air conditioners.
But if your I/O is not so aligned, the driver must provide a kernel buffer - necessarily resident in physical memory, copy your buffer into its Bounce Buffer before using DMA to write the bounce buffer to the device.
If we refactored our client code so that we didn't use Bounce Buffers to often, maybe Pacific Gas & Electric won't have to keep so many nuclear power plants operating long after their originally design lifetimes.
Maybe people who like sushi won't die of mercury poisoning so much because we won't need to burn so much coal. Maybe Chinese schoolchildren won't be dropping like flies because their asthma cannot tolerate the air pollution in Beijing.
While educated as a Physicist, and having plied the trade of software engineer most of my career, I am now a Process Architect [warplife.com]. My dear friend Regan F. Gill of Berkeley, California, is also a Process Architect; it was she who clued me into maybe that I should be one.
But the kind of Process Architecture she performs, is to fly First Class over to South Asia then come down like a Marine Corp Drill Instructor whenever some poor Dalit neglects to unit test his deliverables before checking them in.
My kind of Process Architecture is to call the Director of Software, co-founder and major stockholder of the company I actually work for an Ignorant Mother Fucker to his face, get fired for doing so, then register his name as my own domain, then use that domain to publish such gems as:
That kind of thing led the Corporate Secretary - a Board of Directors Member - and General Counsel of a multinational Body Shop by the name of Oxford Global Resources to overnight a completely baseless seventeen page legal manifesto from Boston to San Jose, then to have it hand-delivered not to me, but to my fucking LANDLORD by a courier, with the best Edward Brown being able to come up with is that I must comply with his demand to cease and desist because I had been, and I quote "Unprofessional".
I feared that Lazara would sue me for libel, but it's not any manner of offense to register a given human name, use it for any purpose other than defamation, to express G-d's Gospel Truth, and even call someone a bad name. It turns out that the United States Supreme Court has held that offensive language holds no expressive content whatsoever. There wasn't squat that Eddie Brown nor Brian could do about it.
However, I had some cash flow trouble so Lazara snapped up the domain when I was unable to renew it.
Now don't get me wrong it is of vital importance that we find a way to employ lots more Process Architects such as Regan who are effective at working within the system.
My take is that we need a few - not a whole lot, but a few - such as myself, who like to spraypaint graffiti on the windows of Manhattan financial firm highrises.
In this respect I am inspired by Harry Tuttle, the sanitation engineer who had a price put on his head in Terry Gilliam's Brazil.
In Memoriam
(Score: 1) by Doctor on Friday March 07 2014, @07:23PM
Sure you can refactor code to save memory too and we can all go back to 512K of memory. Problem is that programmers cost more than hardware now, so the easy solution is thrown more hardware at it. At the end of the day, no manager is going to give a crap if your code uses the processor more efficiently.
"Anybody remotely interesting is mad in some way." - The Doctor
(Score: 1) by shortscreen on Friday March 07 2014, @07:54PM
Considering the state of software development in most areas of the industry today, your statement that accounting for cache efficiency could save electricity is like saying that adjusting my ignition timing by one degree could save fuel (when my fuel tank is made out of paper mache).
(Score: 2, Interesting) by MichaelDavidCrawford on Saturday March 08 2014, @09:36AM
FB-DIMM Dynamic RAM (Fully Buffered Dual Inline Memory Modules) is far faster for multithreaded code because one can read and write into the same locations from two more more different cores simultaneously.
However it draws a lot of power and generates a lot of heat, so it has fallen out of style, to be replaced by the far slower - for multicore access - DDR-3.
If you were to take my advice your users could use FB-DIMM without being concerned about their power consumption or heat generation.
I have a major product announcement [warplife.com] coming 5:01 PM 2014-03-21 EST.
(Score: 0) by Anonymous Coward on Saturday March 08 2014, @12:55AM
Oh look, the famous Kuro5hin troll graces us with his bile. I'd rather have Cold Fjord...
(Score: 2, Interesting) by Katastic on Friday March 07 2014, @07:21PM
So let me clarify. I'm not saying it's bad technology or bad research. I'm saying it's stupefyingly silly to talk about what we can do with the end result of something that is barely passed the stage of formulas in a PDF. How long have memristors been around? And they're just getting to the point where we can put useful groups of them on wafers.
What if we find out five years later, that this magical new technology has a magical new flaw that makes it hard to use for transistors? The tale of Graphene anyone?
(Score: 3, Interesting) by Khyber on Friday March 07 2014, @08:03PM
We were using this same idea for at LEAST two decades to make more efficient power supplies.
Anyone that tries to patent this tech should be shot on sight.
Destroying Semiconductors With Style Since 2008
(Score: 3, Funny) by bd on Saturday March 08 2014, @04:31AM
We were using this same idea for at LEAST two decades to make more efficient power supplies.
You were forming a quasi-particle of the spin of electrons with waves in a piezoelectric crystal to transmit information, thereby transmitting it without actually moving electrons, eliminating capacitive losses?!
In _power supplies_?
The spin of electrons decays in a matter of picoseconds, at best, by multiple scattering processes in the conduction band of semiconductors. You do not SEE spin effects in normal electronic devices at room temperature. While the device these researchers produced will probably not scale to the size of current transistors, as the piezoelectric substrate with ferroelectric layers on top sounds complicated, I do not agree that it is not novel because of power supplies.