Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re:how about .... (Score 1) 131

And where on the label does the Facebook app say how much data it's going to use?

And how about the fact that for a long time, the FB app was fine, and then a change that FB pushed out to folks surprised them later only after they were using it?

It's worth remembering that not using the facebook app is supposed to hit facebook harder than yourself.

That's only true if there's a wide-scale boycott. Otherwise, network effects suggest you're wrong. It's like arguing "Not using Windows is supposed to hit Microsoft harder than yourself." BS. Microsoft hasn't felt a thing since I switched to other platforms years ago. I, however, have had to deal with incompatibilities and quirkiness. For the vast majority of users it never made sense to switch from Windows and it still doesn't, and the reason why is network effects.

Your arguments remind me of the 'Countepoint' guy from Airplane.

The issue here is that most smart phone plans make you, the user, responsible for paying for the total amount of bandwidth consumed, but the phone and the apps don't give you a good mechanism to allow you to act on that responsibility in a meaningful way. Saying "Well, then, don't use it" is unhelpful and unrealistic.

Comment Re:Misleading wording. This is not autoplay. (Score 2) 131

On my BB10 (which I otherwise quite enjoy), many websites will autoplay video. I'll click on an article to read it, and then 10-15 seconds later (sometimes faster, sometimes slower), it'll freeze and force me into a full screen video due to autoplay. Sometimes I can get it to stop quickly and can go back to the article, but quite often I just swipe to make the video not-full-screen and immediately close the page.

That gap between opening the page and getting hijacked by the video appears to be buffering time. That burns bandwidth my connection before I even get a chance to know it might be happening. And, as you say, it's a special kind of awfulness. I'd love to disable this autoplay, but there doesn't seem to be any option for this. (FWIW, disabling Flash doesn't do it.)

At least FB has a setting where you can disable this. The fact it's taken multiple 'news' articles on multiple websites to get the word out, though, hints that FB's roll out of the feature is antisocial at best. If nothing else, they should have defaulted it to preloading only if it was operating over WiFi.

Comment Re:how about .... (Score 5, Insightful) 131

Ok, so you're saying "never launch the Facebook app" is the only responsible choice? These are videos that autoplay without audio when they're not even visible on the screen, so you don't even know that this is happening. (Ok, for the FB app, there is a setting to disable this, but the fact that people haven't heard of this without multiple news articles on the topic says that FB's default caught a good fraction of their users by surprise.)

I personally have been bitten by autoplay ad videos on my BB10 when trying to visit news articles. I haven't found a way to disable video auto-play on this phone with its browser at all. (No, disabling Flash doesn't help.) Are you saying that the only responsible action is to never browse the web from my phone, so I never get bitten by a website that might spring an unwanted, unwarranted (and usually unrelated to the article) video on me? If I browse the web, I'm irresponsible?

Please, do explain how personal responsibility plays a role here, and what it translates to for someone who has no interest in viewing any videos ever on his/her smartphone unless they explicitly ask them to be played. Do tell me how to rectify this moral failing.

Comment Re:Lightfoot (Score 1) 168

Wires on silicon aren't a vacuum. The dominant effect is actually RC delay. As you make wires smaller, the resistance goes up (inversely proportional to cross-sectional area). As you make the wires closer together, capacitance goes up (inversely proportional to distance between the conductors). So, as geometries shrink, propagation delays for real signals in real wires on real silicon go up.

I won't even get into buffers which are required to recondition the signal on long routes... (Someone elsewhere on the thread already did.)

Comment Re:can't cross chip in one clock. big deal. (Score 1) 168

Sure, throughput is what matters most for operations you can parallelize. However, as Amdahl's Law cruelly reminds us, there's always parts of the problem that remain serial, and they'll put an upper bound on performance. You can't parallelize the traversal of a linked list, no matter how hard you try. You have to invent new algorithms and programming techniques. (In the specific case of linked lists, there are other options that trade space for efficiency, such as skiplists.)

Gustafson's Law does offer some hope: As we build more capable machines, we'll tackle bigger problems to utilize those machines. That's how we're able to, for example, get wireless data speeds on our cell phones operating on batteries that would make wired modem users of just 10-15 years ago jealous.

But, Gustafson's Law only serves as a counterpoint to Amdahl's Law to the extent that you tackle bigger problems, as opposed to trying to reduce current problems to take less time and energy.

Comment Re:Why not integrate entire C-library functions? (Score 1) 168

And you think printf() and strtol() are major bottlenecks worth dedicated silicon area why?

Modern CPUs already have many accelerators for high end functions, such as numerical computations, cryptography, and the all important memcpy. (Memory copies are a traditional bottleneck, and general enough that they can be easily offloaded.) They come in two forms—specialized SIMD/vector instruction sets, and dedicated blocks for high-level functions that take multiple microseconds. An example of the former are the SIMD-oriented AVX instructions found on modern x86 chips. As an example of the latter, chips aimed at high end signal processing often have discrete blocks such as FFT accelerators. Others aimed at network tasks (especially DPI) have regular expression engines.

The problem with accelerator blocks is that they do take up area. And if they're powered up, they leak. Leakage current is a significant factor in modern designs. To get faster transistors, you need to drive their threshold voltage down. As you lower the threshold voltage, their leakage current goes up exponentially. So, that circuit better be bringing a lot of bang for the buck if it's going to be sitting there taking up space and leaking.

Another issue with dedicating area to fixed functions is the impact it has on distance between functions on the die. In the Old Days, you could get anywhere on the die in a single clock cycle. With modern designs and modern clock rates, cross-die communication is slow, taking many many cycles. So, when you plop down your custom accelerator, you have to figure out where to put it. Do you put it right in the middle of the rest of the computational units, slowing down the communication between their functions (either lowering clock rate or increasing cycle counts), or do you put it on the other side of the cache, meaning it takes several cycles to send it a request and several cycles to see the result?

This is why many custom accelerator blocks out there today focus on meaty workloads. A large FFT still takes a good bit of time to execute, and there's usually other work the main CPU can do while it executes. Thus, the communication overhead doesn't tank your performance. printf(), on the other hand, generally shows up right in the middle of a bunch of other serial steps. You can't overlap that with anything. Hauling off to a printf() accelerator block generally would make zero sense. If you're really spending that much time in printf(), you're better off rewriting the code to use a less general facility.

A final issue with dedicated hardware is that you can't patch it. Someone finds a bug in your printf() and you're back to using a library version. I could go on, but I think I've made my point.

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...