etep

Gate count is not the issue - the issue is L1 timing. For clocks at 2 GHz plus, there can be very few stages of logic in between flops. Just decoding an address to a one hot wire (necessary to access the memory bank) takes up a good chunk of that time interval. Reading the bits out and resolving them to back to full rail also takes time. Checking for a tag match, more time. Routing that back to the register file, yet more time. If it's not the L1 cache, say shared L3, the total time of flight across the chip is multiple clock cycles, not to mention all the aforementioned time penalties in addition to the longer access latency into even larger shared L3 cache.

Relatedly, in the L3, there is a hash function used to distribute different address to different regions of the L3. The cost of doing this is less significant in two ways: the L3 access latency is already much much higher (as elaborated on above) and the hash calculation can be done in parallel with other required logic (e.g. in parallel with L2 access).

Wow. Am currently reading "The Mockingbird Next Door" by Marja Mills. Brifely, Marja gained unprecedented access to the private life of Nelle Harper Lee. It is extremely interesting, and I am quite surprised at this turn of events. Good news!

Version number is micro, this is a macro question, to wit, the following:

When I converted a perl script to python and saved 50% LOC I didn't know which version of which I was using. Am only vaguely aware of the Python 2.x vs. 3 issues. Never was aware of Perl 5 vs. 6.

When Python and Ruby fade, I look forward to the hand wringing about how version whatever didn't get pushed out fast enough. But that won't be the reason.

A link to the ISSCC keynote by Mark Horowitz, curator of cpudb. IMO worth a listening to for most anyone interested in CPU performance related issues. http://isscc.org/media/2014/plenary/Mark_Horowitz/NewStandar...

The plots shown in his presentation basically show off the underlying data in cpudb.

So basically e-commerce sites are charging me more?

Obviously, but I edited my comment. My inner pedant jumps for joy.

I'm not sure if this is meant to contradict my comment somehow, but I think we are saying the same thing -- read differently, it sounds like you might be suggesting they don't even need the new data. Whether on VMS, or notice to mariners, or whatever, what they had was a report of discolored water. Different, therefore from new data revealing underwater topography.

Removed redundant and pedantically incorrect extra use of word "new".

I hope the U.S. Navy incorporates this into their nautical charts, but, sadly, I doubt they will. I wonder if this data would have prevented the 2004 undersea collision of the USS San Francisco. see, e.g., http://en.wikipedia.org/wiki/USS_San_Francisco_(SSN-711)

I never knew about this place, but now I'm certain I will be getting in the water there soon.

So you're saying there is a self referential satire of the religion of lisp + emacs. That is good ;)

This is not a half baked study. The right comparison is being made, namely performance versus energy. Further, they attempt normalized comparisons, here quoting:

To factor out the impact of technology, present technology-independent power by scaling all processors to 45nm and normalizing the frequency to 1 GHz.

I disagree. The writing is excellent: pragmatic and insightful at the same time. In fact, your quote is a great example of its high quality. I don't need, nor do I like, the heavy handed style of some authors. Eloquent JS is eloquent both in its writing, and in the fact that it elevates javascript.

wow, that is awesome

> The password quality is just adequate, but I think the idea has potential to be very secure.

The op makes no broad claims. I think your insights are helpful, but I would change your wording from "Congratulations" to "unfortunately" and then politely point out how to resolve the issue.

The author of the paper follows this quote with a rant against the referees for scientific journals and conferences. Perhaps I should have quoted that. There must be a reason why Lamport, Knuth, etc. don't write in this style. But, their work is considered significant and historical. It makes me suspect that this is either not significant (why isn't this making headlines like Heartbleed?) or isn't novel, or isn't practical (really), or some combination of the above. If these claims were as significant as claimed, then they would certainly be greeted as such.

Further, from the IACR website: Papers have been placed here by the authors and did not undergo any refereeing process other than verifying that the work seems to be within the scope of cryptology and meets some minimal acceptance criteria and publishing conditions.

Finally, a quick perusal of Google scholar makes their work look at least somewhat non-unique, but again, I am not sure. Let me repeat, it is just their style which set off a small alarm bell.

Usually statements such as "This paper has some serious significance both scientific and historical." (quoted from the article) are a flag of the exact opposite.

I would need more context from a more trusted source to inform my own opinion on this work.

The number one thing to know here:

In most programming languages, each statement is implicitly sequenced, unless told otherwise (e.g. pthreads, or openmp)

In a hardware description language, each statement is concurrent with all others, unless explicitly sequenced.

But this does not even begin to help, i.e. if this is truly for a beginner -- especially in light of the fact that verilog itself is laden with gotchas.

The approach taken by chisel: https://chisel.eecs.berkeley.edu is imo a good one. Each line of code in chisel adds a node to a DAG. The DAG describes the connectivity of logic elements. Sequencing is of course handled as well, so you can view your logic as a set of DAGs with registers in between.

A good point, and I would agree that Haskell is a good candidate for HDL. The following project nicely captures what I think of as a good direction (except for dependence on the JVM which is cross platform torture): https://chisel.eecs.berkeley.edu

In a general purpose language, every line of code is implicitly sequenced, until told otherwise (e.g. for each in parallel, do...)

In a hardware description language, every line of code is executed in parallel, unless explicitly sequenced.

QED

I think it would be interesting, or at least instructive, to try and teach the HDL version of thinking to an untainted student.

So this would be limited by main memory bandwidth, if implemented correctly, but I doubt it even is limited by that right now (i.e. because it is apparently single threaded, and one core typically won't be able to saturate main men bandwidth). The author should measure this and find the active limit (instruction retire or mem bw); perhaps then he will find insight.

How I Became a Famous Novelist by Steve Hely

Should be running out of energy.

Inspirational.

If the real issue is simply to minimize the number of pages to track (and thereby maximize TLB hits) then its very simple: go to 1 GB (or higher!) pages.

This hints that there is a tradeoff happening here. At the highest level, the tradeoff is between having efficient use of memory and TLB hits. Big pages give TLB hits, small pages make efficient use of memory.

Since the TLB is in hardware, it is more difficult to have the fine-grain tuning you desire.

Both would be best, but they are actually independent.

Hardware support for virtualization is actually one of the main things driving huge pages. For a TLB miss in a guest, you end up doing a nested page table walk. This is much more expensive with 4 KB pages (i.e. as opposed to 2 MB).

Short answer: huge pages are a big win for virtualization.

I think it is much simpler. 4 KB pages are small today, and 1 GB is still very large for most processes. 2 MB sounds about right (gut check, how much memory does the average process allocate, and for those small processes, is 2 MB that much overhead really?). Unless the number of TLB entries drops as page size increases, then larger pages make sense. It's simple: 1 GB risks wasting memory when the process doesn't need that much. 2 MB is good in 2014.

Paging is not fast, period. I think it's a reasonable assumption that the machine is not paging. That said, if you rely on paging, then your comment holds.

why brew in favor of port (macports)? any particular reason -- just curious.

inefficiency can infer