This would completely break any event driven (streaming) parser.
2,382 karma · joined November 17, 2012
In my case I had 1 software thread per thread, I'm not sure if over-subscription would make any difference. Also, out of ordering processing is only possible in the absence of data dependencies (I have no idea how to even go about measuring this). Also tree structures are no different to random walks from the hardware's perspective, i.e. the hardware has no useful predictive ability to prefetch data in this case.
The main point was that it's so cheap to test, there's little value in speculating about architecture specifics few are qualified to understand, assuming they're publicly documented in the first place
I was surprised to discover that with a workload composed entirely of XML parsing using Python+lxml, an OVH 1.8ghz Atom N2800 beat hands down my mid-2010 2.4ghz Macbook Pro. This isn't a crazy result either. For instance, while the Macbook is equipped with dual cores, each core supports only one hardware thread, and thus is blocked while waiting to complete a load from RAM (a common occurrence when dealing with giant cache-unfriendly DOM trees that don't benefit from the Core 2's much increased L2).
In contrast the N2800 has 2 cores with 2 hardware threads each (hyperthreading), so each core can progress while its buddy thread is stalled. In my particular workload this was enough to beat by a significant margin a much faster, expensive and power-hungry processor.
I'd also be interested to know if polling mode was tested with any of the cards, and why it didn't work out
Now the tech front is reversing its position, and hopefully the rest of society will eventually follow. Unfortunately the scene isn't set just now, because there simply aren't good alternatives to Gmail – nothing free or self hosted comes remotely close to its clean UI.
When such a thing exists, selling regular users on moving away from Google will be a much easier proposition
[If you're reading this and thinking of cloning Gmail – for fuck's sake don't waste your time "innovating" on the UI and getting it horribly wrong! (This was really the biggest tragedy of the Reader transition). Do a pixel perfect conversion. Except for artwork, cloning a UI is perfectly legal as demonstrated by case law going back 20+ years in the EU and USA.]
The phone is hardly ruined, it's just a high end handset for people in a particular niche, one I happen to belong to (long gave up carrying real cameras, don't give two heaps about Android/pointless OS wars or "mobile apps" or any of that crap, adore the notion of a reasonably high end camera that requires zero effort to bring with me).
Design is often about trade-offs, and based on the parent comment, you seem to have entirely missed the point of this particular design.
The single "lock free" idlep looks like it's just moved the futex contention elsewhere. This will almost certainly bounce like crazy on a many-cored system. Would be interested to see benchmarks of the new design before considering it somehow better.
we encourage providers of feed systems and related tools to connect their
automated systems for feed acquisition to our PuSH hub (or other hubs in the
PuSH ecosystem).
Google directly hosts many feed producers (e.g. Blogger is one of the largest
feed sources on the web) and is a feed consumer too (e.g. many webmasters use
feeds to tell our Search system about changes on their sites). Our PuSH hub
offers easy access to hundreds of millions of Google-hosted feeds, as well as
hundreds of millions of other feeds available via the PuSH ecosystem and
through active polling.
In the meantime I'm left wondering just how much global travel information now finds itself in the hands of the US feds as a result of the purchase.
Aah.. Django.
Seriously, 20ms isn't good even for Python. That's not something to be proud of, that's reason to rip up whatever overelaborate mess you've constructed to figure out just how you're blowing so much time.
As a reminder, a 200 byte HTTP request can be parsed in around 600 instructions or less (about 250 nanoseconds at 2.4ghz).
def python_di_copyright_2069_hosay123(dep, *args, **kwargs):
modname, _, classname = dep.rpartition('.')
mod = importlib.import_module(modname)
return getattr(mod, classname)(*args, **kwargs)
We just published it under Google's Github to give a terrible project implied legitimacy that it likely doesn't even have internally.
Not sure why, but Firefox definitely seems to have a weak spot around 2d (SVG?) performance
No Anders & co didn't just add whatever they felt fashionable, they've designed a language over the course of a decade with (to my knowledge) zero warts, bringing to the table more than 20 years of prior design experience (Turbo Pascal, Delphi).
If it weren't for the stigma of being a Microsoft design, C# would be a hugely more popular language.
And what happens in the case of a package not available through apt? ("Sorcery! All applications must be packaged! All shared libraries must be packaged individually!")
And there went your afternoon installing some just-slightly-uncommon piece of software
And no I'm not suggesting some equivalence between women and cockroaches, I'm objecting to their frivolous dismissal of the project on the grounds of it not being a "creative work".
I'm pretty sure no self-respecting engineer would ever attempt to design such a thing (although many might be deluded into thinking that e.g. advanced type systems might help achieve that goal).
> choice of using C++
Almost certainly not a good indicator.. much of those LOC are likely integrations from other projects. Who is to say the alternative didn't involve rewriting some more sensitive, costly-to-produce code in Ada?