Slashdot Mirror

> Does still not make sense. The cost for a particular function is the exact same regardless where you call it.

Do you even understand what an Instruction Cache is?? And the importance of locality?? Too -much- inlining can be worse then not enough inlining. If had actually worked on a C++ compiler on consoles then you would understand.

On PS3 some games can have a performance delta upto ~10% depending on a) the DISTANCE away non-inlined functions are, and b) HOW MANY functions are inlined. I'm talking from real world experience not from your theoretical clueless assumptions of how CPUs work.

In theory every memory access has the same cost (time), in practice the 3 levels of cache show a wildly varying performance difference.

You really should read: "What every programmer should know about memory"

http://www.akkadia.org/drepper...

Before continuing to spout off your ignorance.

That's a bogus argument.

Real should be replaced with "Good". Are there "good" Javascript, Java, Visual Basic, etc., programmers? Yes there are always exceptionally gifted people -- however that is not the norm as those language encourages sloppy design principles. If programmers come from a C background they tend to be "better" programmers:

ALL good programmers understand TINSTAAFL. Namely,

* Floating Point
* Memory
* Pointers
* Budgets: CPU budgets, Memory budgets, Disk budgets, Network budgets, People budgets (such as programmer time vs machine time)
* Macro-optimization = Algorithm
* Micro-optimization = Assembly language
* GOOD programmers understand both the strengths and weakness of high level programming languages and low level programming languages. They are not married to the dogma of "one size fits all" -- they are aware that each language was designed to solve certain types of problems. They use the right tool for the right job.

I would also add unless you can read assembly language you're probably not as good as a programmer as you think you are.

I still maintain the "last good programmers" were those that could read 6502 assembly. Later generations are mostly clueless about the implementation costs.

http://www.akkadia.org/drepper...

Ulrich Drepper has some x32 benchmarks on his blog. The biggest difference is for the cacheline benchmark where x32 is the same speed as x86_32 but x86_64 is 75% of the speed.

In all the other benchmarks the difference is much smaller and there are some surprising results such as x32 being slower than x86_32 (nbench (FOURIER)) and slower by a large amount compared to x86_64 (PARSEC blackscholes SIMD)...

The OP is right that there's no point in using a high speed naked hash algorithm, but BCrypt isn't the only good alternative.

There's also SHACrypt-256 and SHACrypt-512, which have been supported in GNU LibC since October 2007.

Wikipedia has a pretty thorough discussion of the various password hash routines that are in use on Unix/Linux systems, for that matter.

These days, you do have a quite reasonable alternative to BCrypt available as well, which is Ulrich Drepper's SHA2 based Crypt scheme. It's functionally the same as BCrypt but with the use of a different basic cryptographic operation. Like BCrypt, Drepper's sha-crypt is designed to be as slow as molasses, with the ability to make the operation even slower if you like by explicitly specifying the number of SHA256 or SHA512 passes to perform.

Drepper's SHA256 and SHA512 based Crypt routines are now standard in glibc on Linux, as well as on Solaris and HP-UX, and are likely to natively be supported by PHP and the like on those platforms. If you're looking for an implementation in Java, we have one at ftp://ftp.arlut.utexas.edu/java_hashes/.

...If you want to be able to write fast software, I suggest you read Ulrich Drepper's What Every Programmer Should Know About Memory. It's not that long, and very informative.

It's 114 pages of not that long, but who's counting?

I'm not a hardware guy, but what you're saying is out of touch with the design tradeoffs CPU designers already make for the following reason. Memory that runs at CPU speed already exists, that's what registers are. Then you have L1 cache, which takes a few cycles to access, L2, which takes I don't remember, a few dozen cycles, and memory, which takes hundreds of cycles, even longer if the TLB cache is being missed as well. Obviously things go faster if you have more registers, more L1, etc., but it's a tradeoff between cost, opportunity costs, and performance. Even if you had copious amounts of these on-die caches, you'd still want more RAM, so that you'd have something to put into the caches instead of limiting the working set size to the size of the cache! Furthermore, there is a hierarchy of storage that looks something like registers > L1 > L2 > L3 > memory > SSDs > disk storage > LAN > WAN. Of course, disk storage would be behind information stored in memory of another CPU node in a supercomputer, but anyway, the point is that the faster tiers are there to make access to the slower ones seem faster than it would be if the slow tiers were accessed directly. If you want to be able to write fast software, I suggest you read Ulrich Drepper's What Every Programmer Should Know About Memory. It's not that long, and very informative.

Ulrich Drepper has an interesting article from 2007 about updating the UNIX crypt() command to support SHA-256 and SHA-512.

This is currently used in several modern Linux systems, such as Fedora and Ubuntu. I haven't a clue if any of the BSD systems use it.

It does not appear to be rolled into GNU crypt, at least not according to its documentation.

I'd be happy to run with MAC ACLs (eg SELinux), if developers would stop doing things that cause trouble, like text relocations.