You can't be serious: you have just been served information containing the posters opinion of Kurzweil. The post is clearly stated too, not gibberish at all.
I agree that Kurzweil spouts rubbish about things he don't understand. Religious people often do.
In other parts of the world evidence is always accepted even if someone broke laws to get it. IMHO that's the only logical way - if police illegally break into a house and find evidence a crime have been committed there the evidence is still real. Of course the police in question should get some time in prison too.
No it is not possible due to the dynamics of nature and interactions that are essentially impossible to model having large effects in the long run. Those are the same reasons we can't predict the weather for longer periods of time with any precision. + No it wouldn't require communism, it would require a planned economy.
First: I'm not a shill, second: there's no need to eat crow given that the article doesn't say what you say it does, third: Microsoft doesn't deny that _some_ people think Windows is a spy-machine.
How about a chaotic mostly deterministic system? In other words a system where decisions are mostly due to the personality (neutron weighting) but partially due to chaotic behavior of the brain signaling system etc. which makes the result not fully predictable _but_ not random.
Not only have the state of the art in searching normal databases not changed in the last 21 years (specialized cases like web searches excluded), the use of "green screens" rather than a web interface have nothing to do with the quality of searches - the _real_ complaint is that the full capabilities of the existing system isn't used!
No I did not. Women in general doesn't fixate on looks, money nor length of the 2nd-head neck. Just try to be a nice guy instead - not the complainer kind of "nice" which in general is being clingy, strongly dependent etc., most women doesn't want to act as a mother to a grown man. Also women aren't stupid, hiding a misogynistic personality with a "niceness" veneer just doesn't work.
One of the big things about PnP was that MS succeeded in retrofitting soft configuration for ISA cards. Legacy ISA cards doesn't support PnP but most newer ones does, e.g. the Soundblaster 16 PnP.
Compiler writers aren't generally skilled in assembly language programming.
To be fair, neither are most people writing assembly language. Most people I've worked with in this area certainly didn't have an exhaustive knowledge of all the available opcodes and their detailed performance characteristics on every processor architecture we targeted. I'll be the first to admit that I didn't.
However, some of the best assembly programmers I've known have been working on compilers. It makes sense to hire those people to work on code generators used by millions rather than to hand craft assembly for individual projects.
Have you ever written any assembly code?
Yes, professionally, for some years, on several different architectures, and in performance-sensitive applications. These days I read assembly a lot more than I write it, for exactly the reasons we're discussing here.
Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial.
Perhaps, but Pentium 4 was hardly the same as today's major CPUs from the likes of Intel and ARM. It's not as if writing an XOR to zero a register is the most tricky thing to get right any more.
Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.
The thing is, though, that good compilers for high level languages can look at much larger areas of the code and systematically optimise them, thus making better use of finite resources like cache capacity.
Will your hypothetical assembly programmer consistently rewrite their functions to perform the appropriate level of inlining and fusion effects based on context? Modern compilers for some high-level languages already do.
So we are discussing scientific code? General purpose code will not get huge advantages from advanced inlining etc. I don't know what you mean by fusion - the only thing that comes to mind is loop fusion.
And the answer is of course yes.
Will your hypothetical assembly programmer rewrite their entire function a different way with more efficient register allocation if the underlying algorithm changes? (Granted this one is less relevant these days if we really are talking about a relatively high-end CPU with plenty of registers available anyway, but not all CPUs have that luxury.)
I'd hope so given the fact the code have to be rewritten. Register allocation is one area where a good compiler often is better than a skilled assembly programmer as generating the perfect schedule is very work intensive. In practice a skilled assembly programmer will not be far from optimal by simply using heuristics. Even a good compiler today (GCC, LLVM) can have problems with placing spill-fill of registers and that interacts with the register allocator and a lot more.
Will your hypothetical assembly programmer rewrite an entire hierarchy of functions a different way to avoid both blowing the FPU register stack and spilling unnecessarily?
I don't think there would be an hierarchy in the optimized case. IME compilers are very bad in handling the register-stack hybrid while assembly programmers are capable to handle them after a learning period. Intel even made the FXCHG instruction faster so that compilers could treat the FPU stack as a kind of register file.
Or was as nobody not requiring extended precision floats use the x87 instruction set any more.
Will your hypothetical assembly programmer detect implicit parallelism in their algorithms and restructure them to use parallel low-level operations (as in SIMD) and/or m
80x86 was what was written. Also known as x86 (which just removes the first two chars from 80x86). In most cases x86 is used to refer to the 32 bit extension (i386) or, like here, the 64 bit extension. That is also known as AMD64 (as AMD introduced the extension), Intel64 etc. and also x86-64 - which is used in the project in question.
Yes it is. Even a skilled C/C++ programmer will not generally approach the performance of a skilled assembly language programmer, even when rewriting the C/C++ code to be closer to an optimized asm routine. Sometimes the differences are huge.
The C/C++ programmer can spend more time tweaking code as less effort is required for those high-level languages compared to assembly language. In some cases that mean the C/C++ code can be faster (by using a better algorithm) in practice.
That hasn't really been true for a long time, unless your hand-written assembly code will reliably outperform a good compiler's generated code.
Hint: It's a reasonably safe bet that it won't, unless you actually are a world-class expert on the subject, such as the people who write those compilers.
Compiler writers aren't generally skilled in assembly language programming.
Modern CPUs are not the chips your grandpa programmed. They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors that mean what you think will run fast and what will actually run fast may be two wildly different things, even in apparently simple cases.
Have you ever written any assembly code? Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial. Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.
Now if we'd be talking about a strongly skewed architecture like a non-interlocked VLIW your statement would be more correct _but_ not true. A skilled assembly coder would still generate better code than a compiler however with a lot of effort.
Whole teams of very smart people spend years reading and understanding thousands of pages of CPU specs so they can write compilers that analyse and optimize code at the speed of those modern CPUs to generate efficient machine code from it. Even if you can beat them on implementing one simple algorithm in isolation because you can spot something the compiler missed, modern high level languages encode so much more programmer intent than raw assembly that you might still lose out overall because you're disrupting larger-scale optimisations.
The only advantages of high level languages are portability and faster programming. But the disadvantage is a worse interface to the actual execution hardware - and that is a huge disadvantage.
Slashdot Mirror
You can't be serious: you have just been served information containing the posters opinion of Kurzweil. The post is clearly stated too, not gibberish at all.
I agree that Kurzweil spouts rubbish about things he don't understand. Religious people often do.
In other parts of the world evidence is always accepted even if someone broke laws to get it. IMHO that's the only logical way - if police illegally break into a house and find evidence a crime have been committed there the evidence is still real. Of course the police in question should get some time in prison too.
No it is not possible due to the dynamics of nature and interactions that are essentially impossible to model having large effects in the long run. Those are the same reasons we can't predict the weather for longer periods of time with any precision.
+
No it wouldn't require communism, it would require a planned economy.
The servers didn't for at least a period of time. And that's all it takes.
That's why we can't have nice things.
First: I'm not a shill, second: there's no need to eat crow given that the article doesn't say what you say it does, third: Microsoft doesn't deny that _some_ people think Windows is a spy-machine.
Software development isn't free...
How about a chaotic mostly deterministic system? In other words a system where decisions are mostly due to the personality (neutron weighting) but partially due to chaotic behavior of the brain signaling system etc. which makes the result not fully predictable _but_ not random.
But that's really a philosophical question...
Dictatorship doesn't automatically imply fascism, still it's a better link than the standard use as "something I don't agree with".
PS Nazism isn't fascism either - just inspired by it.
I hope you don't connect to websites located in the US or allow data transfers over US, GB, Canadian, Australian or New Zealand networks.
PS don't drink the water - protect your precious body fluids!
Are you sure the development will be moved to China? Otherwise it will still be a Norwegian company operating under Norwegian law.
Sorry for not encouraging the xenophobia...
Are you dense? It's an American saying, not a Norwegian nor a Chinese one.
Not only have the state of the art in searching normal databases not changed in the last 21 years (specialized cases like web searches excluded), the use of "green screens" rather than a web interface have nothing to do with the quality of searches - the _real_ complaint is that the full capabilities of the existing system isn't used!
I hope you are trolling...
If you want to hook up with beauty fixated shallow women maybe you should put some effort in your own appearance?
Most complainers about not getting women doesn't even have a proper hygiene...
*sigh*
No I did not. Women in general doesn't fixate on looks, money nor length of the 2nd-head neck. Just try to be a nice guy instead - not the complainer kind of "nice" which in general is being clingy, strongly dependent etc., most women doesn't want to act as a mother to a grown man. Also women aren't stupid, hiding a misogynistic personality with a "niceness" veneer just doesn't work.
One of the big things about PnP was that MS succeeded in retrofitting soft configuration for ISA cards. Legacy ISA cards doesn't support PnP but most newer ones does, e.g. the Soundblaster 16 PnP.
For anyone interested how PnP was hacked into a bus not designed for it:
http://www.osdever.net/documen...
Hint: if one can't get laid with 5" it isn't the hardware that fails - it's the software (= personality, appearance).
But cyanide is natural so it must be healthy!
Compiler writers aren't generally skilled in assembly language programming.
To be fair, neither are most people writing assembly language. Most people I've worked with in this area certainly didn't have an exhaustive knowledge of all the available opcodes and their detailed performance characteristics on every processor architecture we targeted. I'll be the first to admit that I didn't.
However, some of the best assembly programmers I've known have been working on compilers. It makes sense to hire those people to work on code generators used by millions rather than to hand craft assembly for individual projects.
Have you ever written any assembly code?
Yes, professionally, for some years, on several different architectures, and in performance-sensitive applications. These days I read assembly a lot more than I write it, for exactly the reasons we're discussing here.
Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial.
Perhaps, but Pentium 4 was hardly the same as today's major CPUs from the likes of Intel and ARM. It's not as if writing an XOR to zero a register is the most tricky thing to get right any more.
Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.
The thing is, though, that good compilers for high level languages can look at much larger areas of the code and systematically optimise them, thus making better use of finite resources like cache capacity.
Will your hypothetical assembly programmer consistently rewrite their functions to perform the appropriate level of inlining and fusion effects based on context? Modern compilers for some high-level languages already do.
So we are discussing scientific code? General purpose code will not get huge advantages from advanced inlining etc. I don't know what you mean by fusion - the only thing that comes to mind is loop fusion.
And the answer is of course yes.
Will your hypothetical assembly programmer rewrite their entire function a different way with more efficient register allocation if the underlying algorithm changes? (Granted this one is less relevant these days if we really are talking about a relatively high-end CPU with plenty of registers available anyway, but not all CPUs have that luxury.)
I'd hope so given the fact the code have to be rewritten. Register allocation is one area where a good compiler often is better than a skilled assembly programmer as generating the perfect schedule is very work intensive. In practice a skilled assembly programmer will not be far from optimal by simply using heuristics. Even a good compiler today (GCC, LLVM) can have problems with placing spill-fill of registers and that interacts with the register allocator and a lot more.
Will your hypothetical assembly programmer rewrite an entire hierarchy of functions a different way to avoid both blowing the FPU register stack and spilling unnecessarily?
I don't think there would be an hierarchy in the optimized case. IME compilers are very bad in handling the register-stack hybrid while assembly programmers are capable to handle them after a learning period. Intel even made the FXCHG instruction faster so that compilers could treat the FPU stack as a kind of register file.
Or was as nobody not requiring extended precision floats use the x87 instruction set any more.
Will your hypothetical assembly programmer detect implicit parallelism in their algorithms and restructure them to use parallel low-level operations (as in SIMD) and/or m
80x86 was what was written. Also known as x86 (which just removes the first two chars from 80x86). In most cases x86 is used to refer to the 32 bit extension (i386) or, like here, the 64 bit extension. That is also known as AMD64 (as AMD introduced the extension), Intel64 etc. and also x86-64 - which is used in the project in question.
https://github.com/tthsqe12/as...
Observe: "Welcome to the project of converting stockfish into x86-64".
So what are you talking about exactly?
Yes it is. Even a skilled C/C++ programmer will not generally approach the performance of a skilled assembly language programmer, even when rewriting the C/C++ code to be closer to an optimized asm routine. Sometimes the differences are huge.
The C/C++ programmer can spend more time tweaking code as less effort is required for those high-level languages compared to assembly language. In some cases that mean the C/C++ code can be faster (by using a better algorithm) in practice.
That hasn't really been true for a long time, unless your hand-written assembly code will reliably outperform a good compiler's generated code.
Hint: It's a reasonably safe bet that it won't, unless you actually are a world-class expert on the subject, such as the people who write those compilers.
Compiler writers aren't generally skilled in assembly language programming.
Modern CPUs are not the chips your grandpa programmed. They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors that mean what you think will run fast and what will actually run fast may be two wildly different things, even in apparently simple cases.
Have you ever written any assembly code? Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial.
Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.
Now if we'd be talking about a strongly skewed architecture like a non-interlocked VLIW your statement would be more correct _but_ not true. A skilled assembly coder would still generate better code than a compiler however with a lot of effort.
Whole teams of very smart people spend years reading and understanding thousands of pages of CPU specs so they can write compilers that analyse and optimize code at the speed of those modern CPUs to generate efficient machine code from it. Even if you can beat them on implementing one simple algorithm in isolation because you can spot something the compiler missed, modern high level languages encode so much more programmer intent than raw assembly that you might still lose out overall because you're disrupting larger-scale optimisations.
The only advantages of high level languages are portability and faster programming. But the disadvantage is a worse interface to the actual execution hardware - and that is a huge disadvantage.
You seem to be experienced in being a twat without anything to back up his rant...
So that's your viewpoint. That doesn't make it generally true.