Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:Functional (Score 1) 370

Okay, I'll bite. What would you do with HTML5 or AJAX to improve the Wikipedia experience? For instance, I'm reading the article on cats. What specifically would you do using "modern techs like AJAX and HTML5 to make it faster and show/hide content on demand as needed by the reader"?

Comment Re:see plus (Score 1) 594

In fact I think one can argue that the current incarnation of C++ is a dog in terms of performance. With all of that template "goodness" you are just loping on stuff that Java and C# can do in an easier manner.

Templates carry no run-time overhead, unlike the C# and Java generics, etc. That's why template-driven programming produces such fast code.

Comment Re:fp (Score 1) 594

OK:

typedef struct button {

    long long color[3];

    void (*onClick)(int);
} Button;

Button okay;
Button cancel;
okay.onClick =
cancel.onClick =
okay.color[2] = 0xffffffff;
cancel.color[2] = 0xffffffff;

The C version is probably smaller and faster than your version.

That's incorrect. Your version will produce code that is at best as fast as a class with an inline color setter (that should be in the ctor, really) and an inline settable click function. If you use virtual inheritance to override click instead of passing a function pointer, the C++ will be faster, as modern compilers can inline many virtual function calls when they know the type at compile time.

But, as written, the provided class would produce identical assembly to your code, with in addition explicit construction/destruction semantics and easier invocation.

Oh, and by the way, you left color[0] and [1] undefined on both of your Buttons.

Comment Re:How far how fast (Score 1) 793

If you're pursuing honest discussion, I apologize for the snark.

Generally, on limited (embedded) platforms, the functionality exposed by iostreams isn't needed, as there's no stdio, and no real buffering to speak of. In such situations you'd still get mileage out of STL containers (possibly with a custom allocator), which carry negligible size implications, but not really any of the heavyweight stuff like streaming.

I'm not a huge fan of iostreams myself, but they're worth using for the type safety, and if you can afford a printf call you can typically afford the 250k link.

Comment Re:Subset holy wars; STL without exceptions (Score 1) 793

So write that logic into your allocator. Generally there are two options when your allocator gives you NULL; that's either retry or abort, and writing those into your allocator is trivial. That's what's so good about C++, btw. (You're still incurring no runtime overhead aside from whatever extra cycles you are burning in your allocator with these checks, which you needed anyway.)

Comment Re:Eh? This is how Skype works? (Score 3, Informative) 396

having the worlds largest mobile phone manufacturer Nokia by the balls?

HAHAHAHAHAHAHAHAHAHA, Microsoft + Nokia, taking the world by storm! Windows Phones everywhere! HAHAHAHAHA! They're gonna expand that 0.41 percent market share into something important real soon now!

Anyway, that's all I -- HAHAHAHAHAHAHAHAHA

Comment Re:Not worth it. (Score 3, Informative) 260

This.

With such a wide range of storage sizes, you're going to have serious trouble setting up any kind of redundant encoding. To mirror a segment of data (or the moral equivalent with RAID-5 or RAID-6) you need segments of the same size; those segments are going to have to be no larger than the smallest drive. That means larger drives have to store multiple segments, but that the segments have to be arranged in a way such that a drive failure on one of the large drives doesn't take the RAID down. If the drives can't be bisected -- that is, divided into two piles of the same total size -- this is impossible, and the fact that your range is from .1TB to 3TB implies this might be the case.

Think about it -- it's probably going to take most-to-all of those smaller drives to "mirror" the larger drive to make it redundant (and mirroring is the best you can do with just two drives). But having one side of the mirror spread across 9 drives makes failure laughably likely, to the point where you're paying performance penalties for nothing.

Your alternative is to use a JBOD setup and have just contiguous space across all of the disks. This is the same problem, except when a drive goes you lose some random segment of data. That's acceptable for two or three drives in scratch storage, but you don't want to actually store things on that.

Make no mistake -- those drives are going to die.

Trust me on this; don't go down this road. Your actual options are to either pair up the disks as best you can, supplimenting with strategic purchases, and make 2-3 independent raids (and maybe even RAIDing those, but it'll be painful), or just write the whole thing off, put disks in if you have obvious candidates in your hardware, and donate the rest.

Comment Re:Mr. Wall, please sit down... (Score 5, Insightful) 577

That's actually one of Google's defenses. They didn't copy the entire Java API, just a portion of it. So no, if the ruling is in Oracle's favor (which is unlikely but not impossible), then you can't get away with fair-use.

This is really, really scary for open source and GNU-like projects -- it's an attempt by a corporation to define copyright law in a way that lets big business completely shut down the academic "free exchange" culture once and for all.

This is serious, guys.

Comment Re:GPU programming is a nightmare. (Score 5, Insightful) 57

Half of our department's research sits directly on CUDA, now, and I haven't really had this experience at all. CUDA is as standard as you can get for NVIDIA architecture -- ditto OpenCL for AMD. The problem with trying to abstract that is the same problem with trying to use something higher-level than C -- you're targeting an accelerator meant to take computational load, not a general-purpose computer. It's very much systems programming.

I'm honestly not really sure how much more abstact you could make it -- memory management is required because it's a fact of the hardware -- the GPU is across a bus and your compiler (or language) doesn't know more about your data semantics than you do. Pipelining and cache management are a fact of life in HPC already, and I haven't seen anything nutso you have to do to support proper instruction flow for nVidia cards (although I've mostly just targeted Fermi).

Comment Re:Thanks gcc! (Score 2) 192

This is more handwaving. Let me say it again.

GCC's license has no effect on your source code or your finished binary. It doesn't matter if GCC is GPLv2, GPLv3, or GPLv9. It has no effect. It doesn't matter. It is exactly the same as if it were a proprietary product that you purchased. Better, in a lot of ways, but in no way worse. It doesn't change or affect your license on your final product in any way, and it doesn't require a "legal team" to ascertain that.

LLVM's development has nothing to do with licensing. It started as a research project and continued as a result of GCC's relatively tangled and highly-domained code base. GCC can get away with that because it's good, but there's plenty of room for competitors, of course.

Companies following procedures you describe are shooting themselves in the foot. Are you implying that when purchasing a product for integration in your toolchain there aren't licensing issues? Does your company just buy the first thing on a Google search without considering how it affects your product?

And regarding mixing GPL 2/3 -- again, that's completely irrelevant to the discussion. Your product is not GCC, nor is your code being "incorporated" with it.

Typically this attitude is the result of smear campaigns against vague licensing boogeymen by Microsoft sales people for upper management. Is that the case here?

Comment Re:Thanks gcc! (Score 5, Interesting) 192

This is just fearmongering. It's not complicated at all. If you don't hook GCC's (internal) intermediate code generation to run some custom process on, then you are covered by the compilation exemption.

Configuring your build to output GCC intermediate, retain that output, modify it with an external tool, and resume the build with the modified intermediate code is not something that will happen by accident. The implications of GCC being GPLv3 are, exactly, none.

FreeBSD's philosophical objections to GPLv3 are well known and they have the right to maintain those objections, but that has little bearing on GCC's use for a proprietary end product.

I would be interested to hear about your build process that you feel is likely to accidentally create a non-exempt compilation. Do you have an example?

Slashdot Top Deals

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Working...