And you obviously don't know how a CPU works. Current 32-bit x86 CPUs have 80 bit integer registers (for long-double). The P4 has 8 128-bit SSE2 registers for doing 4 32-bit or 2 64-bit operations in parallel. None of the proposed 64-bit extensions do anything to the size of the floating point registers, and the AMD64 extensions only add 8 additional *visible* SSE2 registers, without changing the size of the internal register file.
I don't know if this "dual 32-bit" thing is very plausible. Being able to do 64-bit operations is perhaps the most useless feature of the upcoming 64-bit processors. The big things about AMD64 is the larger compiler-visible register file and the ability to address > 4GB of memory.
There is no such thing as ARB2. OpenGL2 isn't even an official spec yet. There aren't any graphics cards that support it either. There are such things called ARB extensions, but no such thing as ARB2. ARB2 is the specific name Carmack gave the OpenGL path in Doom III.
Ever heard of Catalyst drivers? >>>>>>>>>>> Ever see how bad they suck on a Linux machine? Even 3.2.5, although those just suck speed-wise, not stability-wise.
Ever heard of DX9 or ARB2? >>>>>>>>>> What's an ARB2? You mean Carmack's Doom III ARB2 path?
Works fine with my GeForce4Go on 2.6-test4. No searing stabs of pain necessary --- Gentoo patched the kernel driver automagically:) What're you running?
Linux has the same mechanism --- its called the page cache. Anyway, this machine has a good amount of memory (640MB). However, memory isn't the bottleneck for the KDE build. kdelibs, for example, is only about 90MB. g++ actually pegs the CPU most of the time. Compiling C++ is just plain slow. Compiling GNOME (about as large, but in C) takes 1/4 the time.
Try compiling KDE. My 2GHz P4 struggles to do it in under a working day. Heck, it takes nearly a minute just to recompile a KDE theme after making a change to it!
You've got it backwards. The efficiency of our farmng cannot compete with that of peasent farming. At least peasent farmers get more energy out of farming then they put into it. Western nations get less energy (in terms of kilocalories) out of farming than they put into it. Literally, they turn oil (or another source of energy) into food.
Actually, lot's of other things, apparently. He only won second place in Physics. He shared that prize with 4 others, then there were 3 first place entries, and a grand prize entry, all in that catagory. On top of that, you had the 3 grand prize overall winners.
Um, for it to be a fusion reactor, the energy output needn't be greater than the energy input. It just needs to be non-zero. Now, a *useful* fusion reactor would have energy output greater than energy input, but jesus Christ we're talking about a college Freshman!
Well, when we keep telling everyone else how our system is so much better, and how we're the "greatest country in the world" its hard to imagine them getting any other impression...
I agree with this assessment somewhat, in that C++ is a generally more nifty language (in the hands of an expert) than most people give it gredit for. However, its got some limitations I wish were addressed ---
It's awfully verbose. Namespaces don't help, because of irritating practical restrictions on the use of "using namespace" in header files.
Its support for functional constructs is very limited. In particular, the lack of type inference and proper lambdas makes functional code painful to write.
C++ is great on the OO and procedural fronts, but its got some major issues with functional and generic programming. And it needs macros:)
Your description is slightly inaccurate. He said that explicitly freeing allows the next alloc to reuse a given chunk of cache-hot memory, while the GC will ignore that memory and allocate a cache-cold chunk instead.
This really makes sense if you understand how JITs work, and understand the nature of the benchmarks. These benchmarks are mostly microbenchmarks that test a particular operation in a tight loop. JITs can compile this loop once and run it directly on the CPU afterwords. This doesn't extrapolate well to situations where the JIT gets involved more often in the benchmark.
In FP, functions *ARE* data. >>>>>> "State" probably would be a better word to use here. A procedural language is all about state. You call a procedure, and it modifies some state. If you want to reason about the program, you have to reason about all the state. In a functional program (rather than an imperative program written in a functional language) function application is primary, and state only exists in function parameters and return values. This minimizes the amount of state one has to think about at any one time.
In both cases you still have data, and still you have algorithms. >>>>>>> You do, but the relative importance of each is different. The whole idea of OO is that you have objects --- which are containers of state. You have some methods that imperitively modify that state. The central paradigm is the manipulation of state. In function programming, state is secondary to functions. You call a function that evaluates something, and state is only relavent to the functions that receive them as parameters, and return them as results.
What makes fuctional languages "inefficient" in some respects is the fact that they in general do not manipulate "state" of some data, but consider data to be read-only and yield an result instead. >>>> Precisely.
Suppose the whole kernal memory is the state of a system, a functional "kernal" would compute a complete new kernal state as a value object. >>>>>>>>> Yep. Now the key thing here is that this makes sense in lots of cases. Take this ICFP contest. The idea is to compute the most optimal path through a track. The only thing that matters is the result. FP makes sense here. In comparison, a kernel is all about state. There is no result to compute, and functions are only useful in that they allow manipulation of state. FP makes much less sense in this area.
Regarding your - hypotetical - question wether a scheme parser written in scheme would be easyer than a standard C/Pascal parser... who knows? >>>>>> I think you misunderstand me. Both languages are writing a parser for Scheme. I choose Scheme because its a traditional introduction to writing parsers. Compare writing a parser for Scheme in an imperitive style (in any language) vs writing it in a functional style (for any language). The functional approach is much more clear.
The asymptotic complexity of a problem has no relation to the programming paradigm you use -- only to your skills in that paradigm. >>>>>>>>>>> Actually, they do. If you're writing in a purely functional language (Haskell/ Clean) you can't use side-effects. As a result, straightforward implementations of many traditional algorithms become more complex. For example, getting purely functional graph algorithms that are as efficient as traditional imperitive algorithms is an important focus of research in functional programming circles. Now, if you're writing a program where state is just a necessary evil, you can get away with using complex methods (monads, language features like uniqueness types) to deal with that state. If your program is *all* about state (like in a kernel) its probably better to write it in an imperitive style.
That's the bit that bothers me, that built-in methods can't always overridden. Like I said, this is largely a conceptual problem I have with CL, not a practical one.
Dylan has some nice features that I didn't find in Common Lisp. Like Smalltalk, Dylan is objects "all the way down." Its also got some nice performance features like limited types and sealing. Overall, its just more elegant because it doesn't have the baggage of evolution and a standardization committe. This makes little difference in practices --- its mostly conceptual cleanliness. But Dylan is my hobby programming language (I do C++ at work) so I get to be arbitrary and choose elegance over practicality. That said, from my experience with Scheme, I have to say the prefix syntax is growing on me, and I'd love to see a resurrection of prefix-Dylan.
Slashdot Mirror
And you obviously don't know how a CPU works. Current 32-bit x86 CPUs have 80 bit integer registers (for long-double). The P4 has 8 128-bit SSE2 registers for doing 4 32-bit or 2 64-bit operations in parallel. None of the proposed 64-bit extensions do anything to the size of the floating point registers, and the AMD64 extensions only add 8 additional *visible* SSE2 registers, without changing the size of the internal register file.
I don't know if this "dual 32-bit" thing is very plausible. Being able to do 64-bit operations is perhaps the most useless feature of the upcoming 64-bit processors. The big things about AMD64 is the larger compiler-visible register file and the ability to address > 4GB of memory.
There is no such thing as ARB2. OpenGL2 isn't even an official spec yet. There aren't any graphics cards that support it either. There are such things called ARB extensions, but no such thing as ARB2. ARB2 is the specific name Carmack gave the OpenGL path in Doom III.
Ever heard of Catalyst drivers?
>>>>>>>>>>>
Ever see how bad they suck on a Linux machine? Even 3.2.5, although those just suck speed-wise, not stability-wise.
Ever heard of DX9 or ARB2?
>>>>>>>>>>
What's an ARB2? You mean Carmack's Doom III ARB2 path?
Works fine with my GeForce4Go on 2.6-test4. No searing stabs of pain necessary --- Gentoo patched the kernel driver automagically :) What're you running?
And we have the biggest dicks too!
I mean, that is what you were getting to eventually, no?
I shop at Home Depot. They suck. My 2X4s are always about 1.75x3.75.
Linux probably knows enough about power management for it to work on most laptops by now.
>>>>>>>>>>>
You'd think so, wouldn't you?
All the reviewers like FFX. So yes, they are *ALL* wrong.
PS> The IGN reviewer didn't sound like he played the game...
Seesh. X was the worst game in the recent history of the series. And people want another one...
Linux has the same mechanism --- its called the page cache. Anyway, this machine has a good amount of memory (640MB). However, memory isn't the bottleneck for the KDE build. kdelibs, for example, is only about 90MB. g++ actually pegs the CPU most of the time. Compiling C++ is just plain slow. Compiling GNOME (about as large, but in C) takes 1/4 the time.
KDE is just an example. Any large C++ program would do. My point was that developers are one of the catagories that need large machines.
The difference is that all the existing apps would need to be recompiled to fully use the 64bit. :)
>>>>>>>>
USE="x86-64" emerge -D world
The smiley isn't a part of the command...
Try compiling KDE. My 2GHz P4 struggles to do it in under a working day. Heck, it takes nearly a minute just to recompile a KDE theme after making a change to it!
You've got it backwards. The efficiency of our farmng cannot compete with that of peasent farming. At least peasent farmers get more energy out of farming then they put into it. Western nations get less energy (in terms of kilocalories) out of farming than they put into it. Literally, they turn oil (or another source of energy) into food.
Actually, lot's of other things, apparently. He only won second place in Physics. He shared that prize with 4 others, then there were 3 first place entries, and a grand prize entry, all in that catagory. On top of that, you had the 3 grand prize overall winners.
Um, for it to be a fusion reactor, the energy output needn't be greater than the energy input. It just needs to be non-zero. Now, a *useful* fusion reactor would have energy output greater than energy input, but jesus Christ we're talking about a college Freshman!
Well, when we keep telling everyone else how our system is so much better, and how we're the "greatest country in the world" its hard to imagine them getting any other impression...
I agree with this assessment somewhat, in that C++ is a generally more nifty language (in the hands of an expert) than most people give it gredit for. However, its got some limitations I wish were addressed ---
:)
It's awfully verbose. Namespaces don't help, because of irritating practical restrictions on the use of "using namespace" in header files.
Its support for functional constructs is very limited. In particular, the lack of type inference and proper lambdas makes functional code painful to write.
C++ is great on the OO and procedural fronts, but its got some major issues with functional and generic programming. And it needs macros
Your description is slightly inaccurate. He said that explicitly freeing allows the next alloc to reuse a given chunk of cache-hot memory, while the GC will ignore that memory and allocate a cache-cold chunk instead.
This really makes sense if you understand how JITs work, and understand the nature of the benchmarks. These benchmarks are mostly microbenchmarks that test a particular operation in a tight loop. JITs can compile this loop once and run it directly on the CPU afterwords. This doesn't extrapolate well to situations where the JIT gets involved more often in the benchmark.
I wonder if he got an iPod with that :)
In FP, functions *ARE* data.
... who knows?
>>>>>>
"State" probably would be a better word to use here. A procedural language is all about state. You call a procedure, and it modifies some state. If you want to reason about the program, you have to reason about all the state. In a functional program (rather than an imperative program written in a functional language) function application is primary, and state only exists in function parameters and return values. This minimizes the amount of state one has to think about at any one time.
In both cases you still have data, and still you have algorithms.
>>>>>>>
You do, but the relative importance of each is different. The whole idea of OO is that you have objects --- which are containers of state. You have some methods that imperitively modify that state. The central paradigm is the manipulation of state. In function programming, state is secondary to functions. You call a function that evaluates something, and state is only relavent to the functions that receive them as parameters, and return them as results.
What makes fuctional languages "inefficient" in some respects is the fact that they in general do not manipulate "state" of some data, but consider data to be read-only and yield an result instead.
>>>>
Precisely.
Suppose the whole kernal memory is the state of a system, a functional "kernal" would compute a complete new kernal state as a value object.
>>>>>>>>>
Yep. Now the key thing here is that this makes sense in lots of cases. Take this ICFP contest. The idea is to compute the most optimal path through a track. The only thing that matters is the result. FP makes sense here. In comparison, a kernel is all about state. There is no result to compute, and functions are only useful in that they allow manipulation of state. FP makes much less sense in this area.
Regarding your - hypotetical - question wether a scheme parser written in scheme would be easyer than a standard C/Pascal parser
>>>>>>
I think you misunderstand me. Both languages are writing a parser for Scheme. I choose Scheme because its a traditional introduction to writing parsers. Compare writing a parser for Scheme in an imperitive style (in any language) vs writing it in a functional style (for any language). The functional approach is much more clear.
The asymptotic complexity of a problem has no relation to the programming paradigm you use -- only to your skills in that paradigm.
>>>>>>>>>>>
Actually, they do. If you're writing in a purely functional language (Haskell/ Clean) you can't use side-effects. As a result, straightforward implementations of many traditional algorithms become more complex. For example, getting purely functional graph algorithms that are as efficient as traditional imperitive algorithms is an important focus of research in functional programming circles. Now, if you're writing a program where state is just a necessary evil, you can get away with using complex methods (monads, language features like uniqueness types) to deal with that state. If your program is *all* about state (like in a kernel) its probably better to write it in an imperitive style.
That's the bit that bothers me, that built-in methods can't always overridden. Like I said, this is largely a conceptual problem I have with CL, not a practical one.
Dylan has some nice features that I didn't find in Common Lisp. Like Smalltalk, Dylan is objects "all the way down." Its also got some nice performance features like limited types and sealing. Overall, its just more elegant because it doesn't have the baggage of evolution and a standardization committe. This makes little difference in practices --- its mostly conceptual cleanliness. But Dylan is my hobby programming language (I do C++ at work) so I get to be arbitrary and choose elegance over practicality. That said, from my experience with Scheme, I have to say the prefix syntax is growing on me, and I'd love to see a resurrection of prefix-Dylan.