Slashdot Mirror

That's the right direction. Apple already has a pretty good version of it. (See below.)

Bounds checking C like this now is weak and very, very late:
https://gcc.gnu.org/ml/gcc/199...
https://www.lrde.epita.fr/~aki...
http://blog.qt.io/blog/2013/04...
http://valgrind.org/docs/manua...
https://en.wikipedia.org/wiki/...

But the grand champion memory debugger is the Mac OS X standard malloc libraries. You can simply set environment variables and instantly get better debugging than most methods on all other platforms. I presume this is because Objective C/C++ is such a pain to debug that they just built in features to always be available, even for production apps.

http://www.cocoawithlove.com/2...

Those libraries are clever because when debugging array bounds corruption and used/free, all mallocs get their own mmapped memory block surrounded by unmapped memory. Plus writing patterns into free / allocated memory to detect writing to freed memory, etc. This is great because it triggers a system signal that debuggers can catch deterministically.

I found and used those techniques on my last big project a couple years ago. The Windows desktop app and imaging C++ libraries were full of errors, memory corruption, struct and 32bit/64bit problems, etc. I had to do a lot of debugging and rewriting to port to Mac OS X, then a lot to solve corruption and threading issues. And found out, the hard way, what a mess the "standard" pthreads API / libraries were. Just spurred me on to switch to C++11 to have standard threads. This Mac OS X built-in debugging along with gdb made it a snap to find all of those kinds of errors, even for code meant for Android, Linux, and Windows.

Or really, lets just damn it all to hell and learn Lisp ... I can just blame someone else when my program is slow.

Nope!

http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf

http://portal.acm.org/citation.cfm?doid=1143997.1144168

http://www.eecs.berkeley.edu/~fateman/papers/lispfloat.ps

Yeah. Learn Lisp first.

Good idea. :) I know /you/ were only joking but Lisp has been held back by a ton of widely believed (and massively ironic) mythology and it is very sad. The only thing really wrong with it is the lack of stuff written in/for it because of its grossly undeserved reputation.

• The OpenSSL MD5 implementation is 14% faster in 64-bit mode than the 32-bit version.
• Ditto for RC4 which is about 50-60% faster.
• I have seen the sequential disk read throughput of an old SATA box jump by +30-40% with a 64-bit kernel, because of the paging overhead of a 32-bit kernel required to access high-memory (ie. memory between 1GB and 4GB).

May I suggest Myths and facts about 64-bit Linux for your reading pleasure ?

• The OpenSSL MD5 implementation is 14% faster in 64-bit mode than the 32-bit version.
• Ditto for RC4 which is about 50-60% faster.
• I have seen the sequential disk read throughput of an old SATA box jump by +30-40% with a 64-bit kernel, because of the paging overhead of a 32-bit kernel required to access high-memory (ie. memory between 1GB and 4GB).

May I suggest Myths and facts about 64-bit Linux for your reading pleasure ?

> Web serving, business processing, database, any GUI interactive application, game engines (not rendering),

A 10% performance increase could be rather significant even in apps that spend 99% of cpu time waiting for input. The gains appear to be a little higher with well generated or hand optimized code.

Have you ever benchmarked your cluster?

``A good substitute for FORTRAN is C.''

So you say, but it has still not superseded FORTRAN. Also, correct me if I'm wrong, but I think there are still issues in C that prevent C code from being as heavily optimized as FORTRAN (pointer aliasing, perhaps?).

``I think people are rather overdoing this trend for creating new languages. I still have doubts whether it's better to use Perl or Python or Ruby or Lisp or PHP, each and every language has fans and detractors, each has advantages and disadvantages, depending on the application.''

This is exactly why Lispers opposed Unix's idea of many little languages: you will end up with a plethora of different languages to learn, and still end up in situations where none do everything you need well. Instead, the argument was, you should build your domain specific languages on top of Lisp, using functions and macros, so that the resulting languages are all still Lisp. This allows you to use all the power of Lisp and all your DSLs all at the same time.

People laugh at Lisp these days, and say it is slow and has a horrible syntax, but Common Lisp is actually a very powerful language with a very simple (but also flexible and extensible) syntax. Performance has, at various points in time, paralleled that of FORTRAN or C. However, I believe this is not one of such times, despite having just read How to make Lisp go faster than C (PDF), which claims CMUCL 19c produces code as fast or even faster than GCC 4.

Lisp contains a superset of the features in Ruby, can be modified to provide the Ruby syntax, and compiles to run faster than Ruby... Why would we want to rewrite a subset of Lisp in Ruby???

"I mean, take Lisp and its performance. Compare it to Ruby's."

Which Lisp? One which (as most implementations of Common Lisp do these days) appropriately and reasonably gets compared to the output of a C compiler?:

http://www.lrde.epita.fr/cgi-bin/twiki/view/Public ations/200606-IMECS

I wouldn't have thought that would be a very fair comparison to make for Ruby.

A lot of bounds checking can be added by the compiler. So it's not so much about dropping the language, as improving the tools. I've seen various gcc patches for C array checking and the backend already looks to have the capabilities in there:

http://www.lrde.epita.fr/~akim/compil/doc/bounds-c hecking.html

Borland CodeGuard also did array bounds checking for C a long time ago.

Hey you might be interested by my 64-bit implementation of MD5. It seems slightly faster than yours (4.8 clocks per byte on Opteron).

>Most truly high-level languages, like LISP (which was mentioned directly in TFA), are interpreted, and the interpreters are almost always written in C. It is impossible for an interpreted language written in C (or even a compiled one that is converted to C) to go faster than C. Completely not true. To start with Lisp is usually compiled. For more on the topic see: "How to Make Lisp Go Faster than C" http://www.lrde.epita.fr/~didier/comp/research/ver na.06.imecs-slides.pdf

My big hairy conspiracy theory would be in the line of super zonda type of organization hiring some of the most skilled crackers and r00ting the boxen all around ... for spamming, ddosing or whatever ... welcome to the Wild Wild Net.

I believe that Richard Stallman wrote most of the original GNU C compiler, although it was derived partly from a portable optimizer from a 1978 Univeristy of Arizona research project.

"GNU `diff' was written by Mike Haertel, David Hayes, Richard Stallman, Len Tower, and Paul Eggert."

"GNU Make was written by Richard Stallman and Roland McGrath."

"Richard Stallman was the original author of GDB, and of many other GNU programs."

The fact of the matter is, the whole Free Software/Open Source movement would never have been more than a miniscule irrelevant niche if not for the GPL.

As far as the GPL goes, Free/Net/Open BSD is doing just fine, and it's not under the GPL licence. Yes, companies (even Microsoft!) are exploiting it's code for commercial gain ... but that's not killing *BSD.

[ if not for the GPL ] There would be no good Free (or even free, for that matter) compilers.

The first reference to the gcc compiler I can find is Februrary of 1987. According to this page, gcc had a beta release in March of 1987.

Yes, it was written by RMS. But to suggest that the GPL is responsible for something that came out before it did is rather incredible, and to suggest that only RMS can write good compilers and give them away is crazy. [ and of course some would complain that gcc isn't a good compiler. ]

RMS did good things for the state of software. I'm not disputing that. But I also tend to believe that if he hadn't, other people would have done much of the stuff that he's attributed with. The GPL may not have ever existed, but people would still be writing software and giving it and hte source away.

You didn't pay, but you didn't get source either and they typically came with an explicit no-commercial-use clause in the license.

It's not like the GPL suddenly made software safe for commercial use. In fact, it often makes companies reluctant to use software because it requires things of them that they're often not likely to want to do. Is this a good thing? I'm not sure ...

I just looked it up and 3-SAT was proved to be NPC in 1974 by Cook and Levin.

The first problem proved NPC was general CNF SATISFIABILITY, by Cook in 1971. SATISFIABILITY can be shown to polynomially reduce to (CNF) 3-SAT (proving that 3-SAT is NPC), and 3-SAT reduces to lots of other problems, which themselves reduce to even more problems (this is the typical way to prove a new problem NPC).

I somewhat doubt that 3-SAT wasn't proven NPC until 1974, because SAT->3-SAT is a pretty easy reduction. (You just introduce a bunch of dummy variables, e.g. (a or b or c or d) becomes ((a or b or z) and (~z or c or d)) and so on; the reduction is linear time in the number of variables in the original expression.)

Here, at EPITA, we have 500-600 NetBSD's desktop.

This a great topic. I've been waiting for the opportunity to ask some questions. At this point I need tools for recording, mixing, and realtime visualization of line input.

I've been using Goldwave for recording. It's a great shareware program despite only being available for Windows. The problem, other than my aversion to Windows, is that when Windows crashes the entire segment I was recording is lost. This is a definately a problem when it's live performances that you are recording.

Gmurf (open source) has a lot of potential but needs more development. The primary thing I'm looking for right now is software that allows me to record and does realtime visual analysis of the input. This is critical for adjusting the recording level to prevent clipping. The second thing I need is a nice open source mixer--one that allows me to adjust recording and playback levels at the same time. As far as the actual recording goes, SoX does an excellent job of recording and uses very little overhead.

My question is: What are the best open source packages for realtime visualization, the mixer, and wave editing?

numb

Wrong, wrong, wrong.

DVD players can play unencrypted media. Many porno movies are unencrypted, and creating free DVD appliances that can play unencrypted media is perfectly legal, and in fact, there is free program for the Macintosh that can play unencrypted media. That media would not exist if existing DVD players could not play it. It is perfectly feasible to produce free (as in freedom) DVD appliances - recording and playback, audio and digital.

Please, please get a clue, and stop spreading this FUD around. Hollywood wants to control their own content (which they have a right to do), not other people's content.