Well, Dylan has the moral equivilent of a for-each (actually, a its got a very flexible iteration protocol that leaves 'foreach' in the dust), and its been around a lot longer than C#. I'm sure other languages have had it for decades before that.
Loop vectorization does not have to do with hyperthreading. Loop vectorization takes code like this:
for(...iterate over buffer...)
for(...iterate over vector...)
do_scaler_op()
And turn it into code like this:
for(...iterate over buffer...)
do_vector_op(...on vector...)
This has nothing to do with hyperthreading. Hyperthreading deals with parallelism between threads, not parallelism within threads. Intel has a seperate facility for the compiler to generate seperate program threads (OpenMP), but the auto-vectorizer does not. The auto-vectorizer works at a much lower level, replacing several scaler ops with a smaller number of vector ops. GCC does not have the analysis technology necessary to do that.
recent icc (7.x, 8) spank about everyone on vector fp due to various reasons (like Intel not releasing a full spec of the SSE2 unit - check out the gcc mailing lists about SSE2, you'll see they didn't have info on timings and so on, hence gcc does only some integer optimization and mostly scalar fp). The major reason Intel spanks everyone on vector-fp is that its compiler does auto-vectorization of code and none of the others do. The auto-vectorization has nothing to do with hyperthreading, and everything to do with taking advantage of SSE2.
no endless list of competing, inconsistent toolkits What are: "the XP common controls," "Office toolkit," and ".NET toolkit" then? Even Microsoft can't pick a single toolkit for their products... If you're stupid enough to think Windows has only one toolkit, then I'm hesitant to take anything else you say seriously.
The *user-level* has been updated to FreeBSD 4.4. The kernel is still Mach 3.x and 4.4-BSD-Lite2. Go download the code and then download Darwin and look for yourself!
OS X isn't based on FreeBSD. The kernel is a modified Mach 3.x and 4.4BSD-Lite2. FreeBSD provided most of the userland, while Net/OpenBSD provided networking and filesystem components.
The Common Controls. This is used by most straight-Win32 apps.
The Microsoft Office toolkit. This is used by MS Office.
The.NET toolkit. This is used by Visual Studio.NET.
These are just the big ones. Popular Windows apps commonly use seperate toolkits. iTunes and Quicktime have very non-native-looking ports. Lots of apps use Borland VCL. OpenOffice uses its native toolkit. Adobe Photoshop Album uses Qt. There are a bunch more less-used ones too.
How do you know they didn't? The size of the heatsink is probably more indicative of a highly clocked card (that has to cool 1.1GHz memory in addition to the GPU core) and a GPU with 200+ million transistors.
1) NVIDIA tried to use low-k dielectrics on the NV30. TSMC's process wasn't up to snuff, and they were late to market as a result. Thus, it is understandable if they are wary of it.
2) IBM is fabbing these chips. Their process is a bit more advanced than TMSC's. There is no indication that NVIDIA has decided against using the low-k process with the NV40.
To clarify. The problem isn't with shader precision (the new NVIDIA will have higher precision than the new ATI), but with precision-lowering optimizations in the game and/or drivers.
That's such a stupid statement, I don't know where to start. Why do you think NVIDIA fucked up the design? By all accounts, the NV40 is very well designed, in response to the less-than-steller NV38. They just realize that the 6800 is a high-end part, and the people who buy it have no problem giving up an extra PCI slot to get more performance. If you're using something like a Shuttle mini-chassis, then the GeForce 6800 is not targetted at you!
A couple of weeks doesn't help you when you just got the NVIDIA card and need to get the first reivews out ASAP. Part of the benefit of being first-to-market is generating the initial buzz.
Or, you could just use KPackage? Pointy-click your way to installation. Still easier than downloading the DMG, unzipping it, finding the Apps folder, and copying the app over.
Qt has significant grottiness that gtkmm doesn't -- it requires a special preprocessor, has duplication of basic functionality like string, and lacks STL support. It has license issues both on Linux and Windows. This is a feature, not a bug. The statically-typed nature of C++, in combination with the ultra-statically typed nature of the STL make for a crappy GUI language. I'm a big fan of C++/STL, but its wholly inappropriate for GUIs, where a more dynamic language is called for. There is a reason why people fawn over Smalltalk and Objective C for GUI programming.
Also, Qt's containers are very different from the STL's. Qt's containers are reference-oriented, and facillitate polymorphism. The STL's are value-oriented, and discourage polymorphism. Using STL containers polymorphically requires dealing with smart pointers (to ensure memory gets freed properly) and introduces the annoying effect of having to use double-indirection while using STL iterators. C++ also offers no support fo introspection or properties, which moc gives you.
The example you linked to isn't an example of a leak, it is an example of unbounded space usage. See, the elements in the list are still referenced, so the program isn't "finished using them."
The only reason I brought up Scheme is because you mentioned it.
Slashdot Mirror
It would do the trick if C++ had proper lambdas (no, Boost.Lambda is not a proper lambda), but it doesn't, so it doesn't.
The difference is that with Qt, you pay to increase productivity, while with Rose, you pay to lower it.
Well, Dylan has the moral equivilent of a for-each (actually, a its got a very flexible iteration protocol that leaves 'foreach' in the dust), and its been around a lot longer than C#. I'm sure other languages have had it for decades before that.
*looks down*.
Nope, I can still see my feet. Need to clip my toe-nails, though...
Loop vectorization does not have to do with hyperthreading. Loop vectorization takes code like this:
for(...iterate over buffer...)
for(...iterate over vector...)
do_scaler_op()
And turn it into code like this:
for(...iterate over buffer...)
do_vector_op(...on vector...)
This has nothing to do with hyperthreading. Hyperthreading deals with parallelism between threads, not parallelism within threads. Intel has a seperate facility for the compiler to generate seperate program threads (OpenMP), but the auto-vectorizer does not. The auto-vectorizer works at a much lower level, replacing several scaler ops with a smaller number of vector ops. GCC does not have the analysis technology necessary to do that.
I love that I can now use "Lisp is FAST" as an argument against C# and Java :) Oh, how the tables have turned.
G++ is pretty damn close to following standards, as is VS.NET 2003, and Comeau C++.
recent icc (7.x, 8) spank about everyone on vector fp due to various reasons (like Intel not releasing a full spec of the SSE2 unit - check out the gcc mailing lists about SSE2, you'll see they didn't have info on timings and so on, hence gcc does only some integer optimization and mostly scalar fp).
The major reason Intel spanks everyone on vector-fp is that its compiler does auto-vectorization of code and none of the others do. The auto-vectorization has nothing to do with hyperthreading, and everything to do with taking advantage of SSE2.
no endless list of competing, inconsistent toolkits
What are: "the XP common controls," "Office toolkit," and ".NET toolkit" then? Even Microsoft can't pick a single toolkit for their products... If you're stupid enough to think Windows has only one toolkit, then I'm hesitant to take anything else you say seriously.
I didn't say it wasn't a BSD. I said it wasn't *FreeBSD*. The OS X guts are considerably more antiquated than FreeBSD.
The *user-level* has been updated to FreeBSD 4.4. The kernel is still Mach 3.x and 4.4-BSD-Lite2. Go download the code and then download Darwin and look for yourself!
OS X isn't based on FreeBSD. The kernel is a modified Mach 3.x and 4.4BSD-Lite2. FreeBSD provided most of the userland, while Net/OpenBSD provided networking and filesystem components.
No. Just, no. There are:
.NET toolkit. This is used by Visual Studio.NET.
The Common Controls. This is used by most straight-Win32 apps.
The Microsoft Office toolkit. This is used by MS Office.
The
These are just the big ones. Popular Windows apps commonly use seperate toolkits. iTunes and Quicktime have very non-native-looking ports. Lots of apps use Borland VCL. OpenOffice uses its native toolkit. Adobe Photoshop Album uses Qt. There are a bunch more less-used ones too.
Asshole. I mean, literally. I clicked on their forum, on a message titled "re: in defense of /." and got the goatse.cx guy. Urg...
How do you know they didn't? The size of the heatsink is probably more indicative of a highly clocked card (that has to cool 1.1GHz memory in addition to the GPU core) and a GPU with 200+ million transistors.
Heh. "basic" for loops in Dylan are just macros for local tail-recursive functions :)
Windows cannot do this. It is way to diverse as well. Hell, Microsoft itself uses 3 different toolkits for its major app lines!
1) NVIDIA tried to use low-k dielectrics on the NV30. TSMC's process wasn't up to snuff, and they were late to market as a result. Thus, it is understandable if they are wary of it.
2) IBM is fabbing these chips. Their process is a bit more advanced than TMSC's. There is no indication that NVIDIA has decided against using the low-k process with the NV40.
To clarify. The problem isn't with shader precision (the new NVIDIA will have higher precision than the new ATI), but with precision-lowering optimizations in the game and/or drivers.
That's such a stupid statement, I don't know where to start. Why do you think NVIDIA fucked up the design? By all accounts, the NV40 is very well designed, in response to the less-than-steller NV38. They just realize that the 6800 is a high-end part, and the people who buy it have no problem giving up an extra PCI slot to get more performance. If you're using something like a Shuttle mini-chassis, then the GeForce 6800 is not targetted at you!
Actually, a big fan is much quieter than a small one. So your hatred of something should go down in proportion to the size of the fan.
A couple of weeks doesn't help you when you just got the NVIDIA card and need to get the first reivews out ASAP. Part of the benefit of being first-to-market is generating the initial buzz.
Or, you could just use KPackage? Pointy-click your way to installation. Still easier than downloading the DMG, unzipping it, finding the Apps folder, and copying the app over.
Qt has significant grottiness that gtkmm doesn't -- it requires a special preprocessor, has duplication of basic functionality like string, and lacks STL support. It has license issues both on Linux and Windows.
This is a feature, not a bug. The statically-typed nature of C++, in combination with the ultra-statically typed nature of the STL make for a crappy GUI language. I'm a big fan of C++/STL, but its wholly inappropriate for GUIs, where a more dynamic language is called for. There is a reason why people fawn over Smalltalk and Objective C for GUI programming.
Also, Qt's containers are very different from the STL's. Qt's containers are reference-oriented, and facillitate polymorphism. The STL's are value-oriented, and discourage polymorphism. Using STL containers polymorphically requires dealing with smart pointers (to ensure memory gets freed properly) and introduces the annoying effect of having to use double-indirection while using STL iterators. C++ also offers no support fo introspection or properties, which moc gives you.
The example you linked to isn't an example of a leak, it is an example of unbounded space usage. See, the elements in the list are still referenced, so the program isn't "finished using them."
The only reason I brought up Scheme is because you mentioned it.