carbonica

It is truly disheartening to see you'd been downvoted when I came into this thread.

The truth is, the OP's domain was probably considered to be in a bad "neighborhood" because his mail server had been compromised for spamming purposes at one point or another. It's dreadfully easy to either misconfigure a mail server or to end up with your mail server compromised.

Regardless, it's easy to hate on Google, especially in a primarily entrepreneurial forum where those posting are often trying to solve tough problems with far fewer resources. But Google is solving tough problems, even when you feel you've been wronged by an algorithm. Gmail has had an unbelievably successful spam filter for years, forcing the competition to rise to the occasion and match it, to the point where people forget how serious a problem spam is. It's not trivial, and it doesn't mean there's a democratic crisis when your e-mails end up in a spam bin. Especially when it's quite likely because your mail server was compromised.

And:

Unknown said...

Agreed 100% with Rachel's comment above. Also, what makes you think Groupon would even accept you? Top tier deal sites (LivingSocial, Groupon) expect established or reputable businesses. You're too new and unproven to make the cut. You also sound naive in general.

Unknown User Stats

On Blogger Since August 2011

Profile Views (approximate) 4

It's close to the same thing, but having more named registers does provide more optimization opportunities. It shouldn't be completely ignored as a good thing.

I mentioned function calls because that's a boundary when an optimizer - either in-processor or in-compiler - is often forced to use memory and not registers. The big-N-register "register window" of RISC processors kicks this problem's ass. But with aggressive inlining already common, these boundaries don't come up as often as you'd think. So the x86-64 calling convention does a pretty damn good job too.

Edit: by the way, I guess I haven't really commenting on TinyVM one way or the other when I responded to you. You're absolutely right and the compatibility is not necessary at all. I think the register count limitation especially is just silly. I pointed out in a different thread that they could double their register count and they'd still fit in a single cache line... they even already have a naming convention (r08-r15) they can hijack.

Yeah - the vast majority of x86 assembly written today is written to take advantage of specialized instructions that aren't available in this VM.

> But in hardware at least, the x86 registers have been found quite limiting on software and performance.

While the doubled register count makes a big difference - especially with the new x86-64 calling convention - register renaming and hidden registers do a lot on x86 to mitigate the lack of general purpose registers. You don't need more than 8 registers to get the benefits of having more than 8.

The instruction set is vastly simpler than x86, but it does inherit some limitations for no reason. x86 had 8 named registers for so long because the mod_rm byte in x86 only has 3 bits for each operand. Adding the REX prefix byte in x86=64 complicates things a bit, but isn't too tough.

This VM doesn't have a particularly compact in-memory encoding - it uses an entire `int` for each argument! They could double the number of registers and the entire register set would fit in a cache line (except for EIP) at 4 bytes apiece. I guess it is nice that all 9 fit in one line now, but I doubt that was considered.

> "Closure" (at least to me) doesn't imply this bevaior in a language with mutable variables.

I don't think I can name a single reasonably-known language with mutable variables and closures that doesn't exhibit this behavior.

I'm sorry? Python is the same way:

    >>> i = 10
    >>> def x():
    ...   print i
    ... 
    >>> x()
    10
    >>> i = 11
    >>> x()
    11

The value is not closed over in any language I can think of off the top of my head. It's a reference to a variable in lexical scope.

What python does slightly differently is writing to variables in outer scopes. But it still closes over references.

But what I pulled out from the Wired article amounted to "it's silly that if the file sizes are slightly different you need to upload your whole song." If file sizes are different, the MD5 will be wrong in nearly all cases. They're talking about something different in that paragraph than you are.

> However, the ruling makes clear that if MP3tunes scanned a customer’s music collection and found “Stairway to Heaven” ripped from a CD with a slightly different file size, the company could not simply substitute a master copy. Instead, that customer would have to upload the file.

> While the latter case still seems non-sensical, the ruling still must come as a relief to Google, Amazon and Dropbox.

Come on, how is that non-sensical? It'd be dead simple to set the ID3 tags of any 4MB mp3 file to match the tags accepted for a given song. From what I read, and the legalspeak got pretty heavy so I may have missed it, there wasn't any discussion of audio fingerprinting or more advanced ways to determine two files are the same song.

Want an entire artist's discography? Use a 15KB app which spits out 100 junk MP3 files with the right ID3 tags and submit them to MP3Tunes. If we do what this author considers "sensical," you should get the real music back.

You've repeated the burrito example in nearly every subthread here, which is poor form to begin with, and it is a horrible example. You are comparing ("chicken burrito" -> "beef burrito") to ("something with words I've never seen in the past several billion searches" -> "something for which I have many results that get many clicks")

Please stop spamming your analogy to every subthread and please consider that it may in fact have some flaws.

Russ is pretty much describing Go as it existed in its developer's minds in 2007. He even explains nearly all of Go's (future) interesting features - with nearly identical syntax - before he even gets to an example.

> Is $10K/month necessary for living expenses?

While at first glance, the "needing 10k/month" seems surprisingly high, it's likely he means "need 10k/month to maintain my present lifestyle." I doubt he actually means "I need 10k/month to survive," just that having a family means less compromising on lifestyle.

If kids are in school, maybe even private school, those expenses are likely something he doesn't intend to compromise on, which is completely fair. If he has a nice home in a nice neighborhood, he still has to pay property taxes. Healthcare costs more for a full family than 1 person. And so on. Sure, there's a path toward having lower living expenses, like moving where property taxes are lower and taking kids out of private school. It's just going to be a lot harder to take.

Not having int64/uint64 is kind of a deal-breaker for any such library. Which means, in JavaScript, a big integer library. I don't see one.