non-e-moose

Former AMD employee here (2007-2012) AMD 'dropped the ball' BADLY when (2012) then-VP Ben Bar-Haim decided to do a software purge, and focused on retaining the over-bureaucratic folks of ATI/Markham. Net result: NVidia was (and did) pick up a lot of very smart researchers and developers from AMD (I know of a couple whom were thoroughly disgusted with AMD management at that time)

He also trashed a lot of good and useful software projects for seemingly protectionist reasons (if it wasn't ATI/Markham, it was dumped)

Seems to me that the goal is to build a funding model. There CANNOT be such a thing as "Safe Superintelligence". A ML system can ALWAYS (by definition of ML) be exploited to do things which are detrimental to consumers.

Unaligned pointer accesses are for 80386 bozos. Period End of story. If you want to play in 64-bit land, live by the architectural rules. If you do not, your code will likely die. And you need to "Lurn" a lot

Silly Rabbit - absolutely accurate times are a security problem. CPU designers (even waay back in Alpha @ DEC) intentionally introduced clock jitter, just to prevent total predictability. For x86, I think if you performed 3-4 of them, and then saved the values in to registers, and then upon completion reported those values, you would find that the time deltas are NOT exactly the same.

Count the number of "authors". Anything above 100 is absolutely garbage More then 10 is probably irrelevant and unproveable.

Because EMACS is not an efficient programming languge

I'm not sure I see the benefits here unless you are buying completely in to: Emacs, and Java and ignoring performance/overhead. Closure is implemented in Java; and the only apparent way to write it is via Emacs. The zero-eth issue I see: functional programming espouses absolutely no side effects, meaning no capability of handling network of physical I/O errors The implementation being in Java means that it is not possible to use it in embedded environments (which might not be a problem for some users) but it does mean that performance is JVM limited. Personally, I find the requirement of Emacs to be QUITE odious. In my opinion, Emacs is an OS/environment and not an editor. I'll use it if I want to edit a binary, but when an editor includes a psychotherapist mode (Eliza) it is not suitable for software development. I have also seen some quite talented researchers/engineers spend multiple seconds trying to remember the sequence to do X in Emacs, when it would have taken FAR less time in vi or vim. Too many parentheses make the code UNMAINTAINABLE in a production environment.

Kenoph: is your company looking for people with experience in binary translation/compilers? My URL: http://gorton-machine.org/rick/index.html and resume hangs off of that. Regards, Richard