Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:Clarification (Score 1) 211

I think it's probably fine to store non-empty cells as objects, as long as you use something like the Flyweight pattern to avoid carrying too much baggage in each cell. It makes for a fine user interface, I'm sure.

To really get good recalc performance, though, you really need to drag the cell dependence graph out of the grid and treat it like an actual program. Once you do that, you could actually JIT the computation represented by all those cells. If you're really walking the object forest for every recalc, you'll never speed up.

Comment Re:Modern morality (Score 1) 24

Actually, I'm on your side, on Federalist grounds, that the DOMA was daft.
I also have precisely zero confidence whatsoever in that piece of work Holder, or the Voting Rights section of the DOJ, and concur with Thomas' remarks on that decision.

Comment Re:Sigh (Score 2, Insightful) 324

The 4th what? Surely you don't mean the 4th amendment? After all, that amendment protects against unreasonable searches, which is completely unrelated to the issue at hand.

The Fourth Amendment's protection of "papers" has never applied to the external surface of mail. The outside of mail must be read by the USPS for the service to function, so when you drop a letter in the mailbox, you're implicitly giving the USPS permission to read the visible surface. To my knowledge, there has never been a law preventing the USPS (or any other courier, for that matter) from reading anything visible from the outside. If the surface of mail is particularly confidential, it's not "unreasonable" to expect the mailer to put it in a plain outer envelope.

Comment Re:They take photos? (Score 1) 324

...Because it's not like your side of the story could possibly be corroborated by receipts, packing slips, or even the actual product.

Surveillance itself isn't inherently bad, but it's an all-or-nothing deal. Once the investigators know you've been receiving packages from $ENEMY, they need to also know that those packages were unrelated to $PLOT or $TARGET, so it's obvious you're just another mundane person.

Comment Re:This is not a tech issue (Score 1) 229

Intel supplies most of Apple's CPUs, yes?

Intel supplies all of the CPUs used in Apple's desktop and laptop computers, yes.

Personally, I think Apple should take their cash and make their own processors

Is that "Apple should take their cash and build their own foundries" or "Apple should take their cash and buy an existing foundry"? In either case, it's "Apple should continue to invest in foundries to update to new processes", and, in either case, I'm not sure how easy that would be.

Or is that "Apple should do their own chip designs"? Anandtech suspects they're already doing that.

allowing for their OS to have a firmware component

If by "firmware component" you mean on-chip firmware, how is owning your own foundry, rather than having another foundry fab your design, a requirement for that? Or does this mean that "Apple should take their cash and build their own foundries" means "Apple should do their own chip designs" rather than "Apple should do their own chip fabrication"?

and thereby boosting performance and security.

What sort of firmware customization are you talking about here?

Comment Re:Ultrabook II? (Score 5, Interesting) 229

Remember when Intel took the MacBook air design and turned it into the Ultrabook reference design for its Wintel PC OEMs? Why would Apple not want that to happen again, only faster?

I disagree. Copying a form factor is not really copying design. That's a bit like saying that every hatchback car today is a copy of the original Japanese hatchbacks or whoever first produced the design. While it is true at one level, it is too simplistic a statement to make.

Anyway - I think the biggest challenge for Intel is not its process technology (process shrinks are going to get a lot harder in every iteration, but that holds true for everyone - including Intel and probably more so for TSMC, Samsung, and others). It is actually not even an x86 vs ARM architecture thing - ARM architecture superiority has pretty much been debunked since Medfield's release.

The biggest challenge for Intel, IMHO, is that it is simply not used to (and not geared for) SOCs. Intel has always designed and manufactured discrete chips whereas the entire mobile industry prefers, nay wants, highly integrated SOCs. This is the one aspect where Qualcomm kicks everyone's butt. To put it another way, Intel's fight is not with ARM or TSMC or AMD. Intel's fight today is with Qualcomm. Intel *needs* to get the same level of integration in its SOCs as Qualcomm - otherwise no one will want a bunch of discrete chips from Intel even if Intel shouts itself hoarse about how much better its chips are. And this goes for Apple as well. If Intel can give Apple an SOC that integrates the CPU, GPU, modems and other chips (I'm actually not an expert here but I would say things like DAC, GPS, etc. - anything that is not MEMS), I have a feeling that Apple will find it very hard to say "no".

I don't mean to sound grand but I honestly feel that the future of semiconductors will be highly integrated one-chip SOC based solutions that are "cheap as chips".

Comment Re:If you need it you are doing it wrong. (Score 1) 211

I agree. Also, if you rewrite structured code into a "performance oriented approach", you are doing it wrong. Write code so it is easy to understand. Then compilers should understand how to make it fast.

I.e., code should be written in high-level descriptive languages, and the compiler should choose the algorithm, so that a tricky-to-understand but much-faster algorithm doesn't show up in the code as written, but shows up in the generated code?

Not all rewrites-for-performance involve low-level trickiness.

Slashdot Top Deals

Surprise your boss. Get to work on time.

Working...