Domain: drdobbs.com
Stories and comments across the archive that link to drdobbs.com.
Comments · 66
-
Re:more nukes :/
Exactly, CUDA has become a major player in the field of supercomputing. Just like IBM's PowerPC/BlueGene systems. With support for Floats/Doubles and amazingly fast math functions and tons of data in Matrices, the only other way to do all that math fast is a FPGA or a PowerPC chip.
CUDA, Supercomputing for the Masses: Part 1/20
http://drdobbs.com/cpp/207200659 -
Re:Not portable.
And let's not forget the RIA aspect, Java FX 2.0 is out and some early Java FX 2.0 adopters say that it looks very good from where they're standing.
-
JUCE
Seems odd that nobody has mentioned JUCE yet.. http://www.rawmaterialsoftware.com/juce
It's a nicely-written Qt-style C++ library. Dr Dobbs actually rated it more highly than Qt in their Jolt awards a couple of months ago: http://www.drdobbs.com/blog/archives/2010/09/jolt_awards_and.html
-
Re:Safety List
Safety control systems, especially those where life and limb, as well as massive amounts of money, are at steak aren't the places to be cutting corners and using commodity products rather than purpose-built and well-tested systems.
Yes, that's why the nextgen ATC system for the US is being written in C++ (secure if you know how to herd cats effectively) (http://blog.seattlepi.com/aerospace/archives/202907.asp), instead of Ada (secure unless you ask a bunch of C++ programmers to write in Ada), whilst the UK is writing theirs using Ada (http://www.drdobbs.com/embedded-systems/199905389;jsessionid=QQKCSEKZREME5QE1GHPSKH4ATMY32JVN) . One of those two is well proven in safety-critical systems. The other is used to write Windows. I wonder which was used for the Deepwater Horizon?
-
Dr. Dobbs
What!? No mention of Dr. Dobb's?
/. is slipping. - Jasen. -
Dr. Dobbs
Dr. Dobbs is the Compute Magazine for grown ups. They cover the current cool stuff (3D rendering, parallel computing, video encoding) and provide the source for download.
-
Re:OK, they're integrated "properly", but...
It's not about graphics. It's about that on-die vector pipeline. Massive SIMD with the throughput to match.
CUDE GPUs blow SSE out of the water by an order of magnitude for some classes of computation. SSE can do 2 x 64bit ops at once pipelined with loads and pre-fetches.
-
Re:I don't use this feature.
With Windows, it's nice to do a clean install every year or so anyway, to handle bitrot.
-
Re:Beware the key term there:
One of the goals was to *not* require a rewrite of applications, and they succeeded on that goal.
This is interesting stuff, but if the goal is to not have to change source, isn't this sub-par? Hasn't the Boehm collector been tested as faster than using malloc/free forever? See http://www.drdobbs.com/cpp/184401632;jsessionid=IRGXEUGCDWGBJQE1GHOSKH4ATMY32JVN for a trivial example (a paper at ftp.cs.boulder.edu is offline, I guess with the server for now).
-Peter
-
Re:Flash and HTML5 make Java look efficient.
When the industry as a whole moved from C and C++ to Java in the late 1990s, one of our main problems was the bloat that Java brought to the table. Memory consumption was a real issue, as was its slow nature. Things have improved somewhat, mainly driven by vast hardware advances.
Interesting take - unfortunately incorrect. Java's performance issues were almost entirely due to the interpreted nature of its code. When it was originally released, all Java code was interpreted by the JVM. The result is similar to running code through an emulator
... often usable, but certainly not competitive with native applications. The introduction of Just-in-time compilation to Java (via HotSpot and similar runtime engines) made all the difference in the world. By Java 1.2 (1998), the JRE came equipped with HotSpot and basic performance became an (often inappropriately cited) non-issue. Hardware advances played as much a role in speeding up Java as it did any other language.Now, when we moved from C and C++ to Java, we did get a huge productivity boost, even if our apps themselves were more bloated and ran slower. Apps that would've taken us a year to develop using C++ could be finished in a couple of months using Java. We could also develop much more complex software than we could using C++. So Java did offer some real benefits, and that's why it became popular.
More info can be found with Google.
Most of the benefits offered by Java are those bestowed upon an application by virtue of running in the Java Runtime Environment (JRE), including automatic memory management (garbage collection), strong exception handling, cross-platform portability, sandboxed code execution, security controls, dynamic class generation, to name a few. Java's syntax is also familiar and effective, and caters to many newer programming models and paradigms. Nothing about Java allows applications to be more complex than they were before... I dare you to find something as complex as the Linux Kernel, or something whose complexity is handled better in Java than via a C++ toolkit like QT. Java's advantages have always been related to its abilities to simplify coding challenges, allowing more effective, secure, and functional code to be produced faster (and with a lower learning curve).
We can't say the same for Flash and HTML5, however. They both suffer from far worse bloat than Java ever did. For instance, take watching videos on YouTube. I just did that using Firefox on Linux, and the Firefox process is now using 3966 MB of RAM. That's its resident usage, not virtual usage, as well. Its virtual usage is currently 4512 MB.
This is certainly a bit subjective. For example, my Firefox running on Linux watching YouTube is only using 80MB of memory, with Flash's "npviewer.bin" adding another 10MB. However, RAM usage is not a bad thing. Traditionally, when RAM came in far smaller quantities than it did now, developers frequently traded extra CPU cycles and disk I/O to conserve memory. Now, it's almost the opposite. A good application, especially a foreground application like a web browser, will use RAM liberally to conserve bottleneck resources like CPU, bandwidth, and I/O. Most of the time, the application profiles the environment that it is running in and chooses how much RAM it will use for optimization based on that profile. A system with 1GB of RAM will likely have big applications like Firefox use significantly less memory than one with 8
-
Re:To be fair
Gee! You think it was a
... *bug*? That was later *fixed*?Gee! *No*...*I don't*!
You really think that a whole series of deliberately obfuscated tests, that could only be passed by MS-DOS and that serve absolutely no other purpose, were added *accidentally*?
Have a look at this for a detailed look at the code. Seriously, tell me *that* is just a bug!
-
Re:Wrong is not strong enough...
"Likewise, Bruce Hogman provided a vertiable trove of COBOL information. According to Gartner, Bruce reports, there are 250 billion lines of COBOL source code being used, with 15 billion new lines each year. A major AAA national company has some 35,000 COBOL modules plus supporting COPY books and so on in its inventory. A major airlines has 848 COBOL modules in its crew management system with some 3,000,000+ SLOC of code. Merrill-Lynch runs 70 percent of its daily business on COBOL systems."
-- http://www.drdobbs.com/blog/portal/archives/2006/10/cobol_and_then.html
I can't say how Gartner comes up with the 250 billion number, but it is one which has been often repeated.
Its funny, see I feel the same way about the other 'P' languages, why should I need to learn another language which does EXACTLY the same things as the one I am already a master of? There is just no compelling reason to use Python, PHP, or Ruby vs Perl. People being what they are, they will always reinvent the wheel, but frankly had all that effort gone into Perl development I have a feeling we'd have one single much better implementation of dynamic scripting...
-
Dvorak wasn't the first to make the prediction
I don't know if he's commented on it since, but Michael Swaine made a small but amusing prediction that this might happen waaay back in the April 1993 issue of Dr. Dobb's Journal. Here's a link to the Google cache version since the original wasn't coming up for me.
-
I am amazed
People should be marching on their state capitols demanding that the current e-voting machines be replaced with verifiable voting methods such as paper ballots until such time as everyone can be satisfied that the e-voting machines are fair and reliable. (Which probably means when they produce a clear paper trail.)
The foundation of our system of government is put at risk by sloppy or malicious coding and we all sit at home and go about our lives as if nothing is truely at risk. The degree of apathy that has been shown on this issue is astonishing.
Avi Rubin, the leading authority on e-voting, gave a great interview in the recent Dr. Dobbs Journel. I think what he says is something that every voter should hear. (His writings on e-voting are here.) The problem is not whether or not a certain political party or company has rigged these machines to fix the election, it's that the very design and nature of these machines makes it possible to do so in a way that is undetectable.
Up until now, if you wanted to steal an election, you had to coordinate the work of a large number of people in across a large number of states unless you could blame it all on a bunch of people voting incorrectly in one county in Florida. Now, you could subtley alter the programming of these machines and shift a small percentage of the results produced by each one. It would be almost impossible to detect.
It's not just the presidential race that is affected, its all the races. Think of the money that is controlled by these politicians and the incentives available to people who want to make sure they get the "right" political climate in the future. If this type of cheating doesn't happen this election, it will happen in another, and soon.
The only way to make sure that these machines can be trusted is to:
- Make the source open to viewing by anyone who wishes to see it. The source should be posted on the Internet and paper copies should be supplied to voters on request.
- Run the software on an operating system that is also open source. It's already been shown that the Diebold machines can be compromised via the Microsoft Windows operating system.
- Produce a paper audit trail and a printed voting receipt that can be used to verify the results the machine reports.
They say we get the government we deserve. If we don't raise hell with out state governments and election boards over the use of these machines, you can be certain of it.
-
The Good and the Bad.
If you like good analysis of current events with a liberal flavor, no one beats The New Yorker ' talk of the town'. You learn a lot about writing and argumentation just by reading their articles plus their cartoons have a well deserved fame. Too bad they almost never write about technology.
To follow current technological trends, you can turn to the MIT technology review is not as watered down as popular science but still is broad on coverage.
Finally, for bad algorithms and outdated programming techniques, you can waste your time with Dr. Dobbs Journal. I don't know if it's not what it used to be or if it has always been bad.
-
Dr. Bob...not Dr. Dobbs