Google to Offer a Best Price Guarantee on Certain Flights - <AUTHOR> https://www.blog.google/products/flights-hotels/best-prices-for-your-trips/ <comment><USER2> Say what you want about Google/Alphabet as a whole, but Google Flights is incredible. It's absolutely amazing how quickly and largely that Google crushed all its competitors in terms of usability. Kayak, Hipmunk, Orbitz, Skyscanner were all my go-to's at one point but G.Flights is far superior in so many ways. It actually remembers your airline preference between searches. You don't have to beg or change settings to see a few days before or after... every search has a date grid and long-term graph, both which respond almost immediately to additional changes to date ranges. Searching multiple airports or destinations is super easy. Plus the calendar view, with lowest price for every day -- sure other sites have it but only for unfiltered searches. Google's calendar view is updated with every filter change.

There was a time in the 90s when eAAsySabre was publicly available to anyone, and text based searches were simple and fast and so easy. But Google Flights is even better, IMO.

Pretty amazing that sites entirely dependent on travel search seem satisfied with 10-year old UI while Google showed how much better it could be.

<comment><USER3> I agree that its real-time inventory and pricing availability has been a total game changer in the UX department. Presumably their acquisition of ITA gave them the ability to respond to queries in real-time which enabled all of the (quite excellent) features you pointed out above.

There's just one problem -- because a ton of the data is cached, or precomputed, or however it's done, a substantial and frustrating amount of the data is simply _wrong_. As in, an unbookable flight. I spend probably an unreasonable amount of time searching for flights, and anecdotally I'd say about 5-10% of the results I get (not even for complex itineraries) either have a completely incorrect price, or are wholly unbookable on any website. Calling the airline doesn't count, because if their website doesn't have it, 99% chance neither will the call center.

For example, one from a few hours ago: [https://www.google.com/flights/?f=0#f=0&flt=/m/01lfy./m/02_2...](https://www.google.com/flights/?f=0#f=0&flt=/m/01lfy./m/02_286.2019-08-14.CPHMAN0SK539~MANJFK0VS127;c:USD;e:1;sd:1;t:b;tt:o;sp:2.USD.40325)

<comment><USER4> This is actually very difficult. The data has to be sourced from somewhere, which would be the airlines. The airlines have fragile backends that cannot handle much load. As a result, Google has to be very selective in their query volume, so they try to cache intelligently.

The result is that sometimes the information they display can be out of sync with airlines. You should notice this issue more on rarer flight routes.

<comment><USER5> > The data has to be sourced from somewhere, which would be the airlines.

Such nonsense.

Pretty much all airlines don't own/run the source of truth for their flights and haven't for decades. They outsource that to GDS[1] such as Sabre and Amadeus. Their backends are not fragile.

You just have to pay for every query thus the caching.

[1] [https://en.wikipedia.org/wiki/Global_distribution_system](https://en.wikipedia.org/wiki/Global_distribution_system)

</comment></comment></comment></comment><comment><USER6> Once their algorithm can predict prices to a certain level of accuracy, they can effectively offer investment hedging to the public for free, and use the publicity to drive commissions on referrals. Unlike other commodities whose value is subject to numerous economic forces, the pricing is set directly (by the airlines), and it is likely that simply by observing their pricing over time a sophisticated Google algorithm has "learned" the airline's less sophisticated ones.

<comment><USER7> But can't the airlines then introduce random price spikes into their own algorithm just to abuse Google?

<comment><USER8> Wouldn't it have to be a price _drop_ for google to be out any money? It's a low price guarantee, so price spikes would only make them look good. Airlines aren't going to randomly drop prices to spite google...

<comment><USER9> It would cost them almost nothing to drop the price of their remaining economy seats 33 minutes before departure on a few select flights where Google sold many tickets.

<comment><USER10> That would be such a rookie mistake. Airlines don't do that, because 1) it creates bad habits with passengers 2) that's when the ticket has the highest value for customer who need to travel NOW 3) if they have remaining economy seats, a price drop 33 minutes before departure has little effect in stimulating demand for most destinations.

<comment><USER9> How many people are in a position to make a purchase decision, buy a ticket, _and make the flight_ when the price drops 33 minutes before departure (13 minutes before boarding ends)?

In June, I was literally in CVG airport (inside of security) when my Delta flight was delayed. I decided not to book a ticket on United that was leaving in ~35 minutes because I wasn't sure that I could get over to the other terminal before boarding closed. (It also wasn't 100% clear that the United flight was going to make the connection in DC because of weather that was also screwing up Delta.)

<comment><USER11> Probably people that miss their flight and are either already in the terminal or past security would like to book it? That's the only use case I can think of

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> > To see your trips and travel research, turn on these settings: Private > results, Web & app activity

This is the main reason why I will never be able to use www.google.com/travel. I used to use the Trips app with no search history, but Google is shutting down Trips in favor of forcing people to loosen privacy settings. It is very disappointing because Trips worked very well.

<comment><USER13> How do you want Google to show you your trips and your travel research (e.g search queries) if you disable search history?

If you don't want to see your search history (since you seem adamant on disabling it), then just use the other features on google.com/travel (destination/hotel/flight search).

<comment><USER14> It's ridiculous because they don't need your location history to search for static content that they already have saved in their databases. The exact same behavior happens with maps: [https://news.ycombinator.com/item?id=19809432](https://news.ycombinator.com/item?id=19809432)

Google is shameless about gimping their services unless you hand over gross amounts of irrelevant personal information.

</comment></comment></comment><comment><USER15> Google putting the finishing touches om the ITA software acquisition.

[https://en.wikipedia.org/wiki/ITA_Software](https://en.wikipedia.org/wiki/ITA_Software)

But oddly closed google trips, which frankly was decent. Google sometimes seems like incoherent.

<comment><USER16> During my business/tech econonomics class in college in 2010, one of the main course assignments was to argue for or against the ITA acquisition from a judicial perspective (i.e. would it create a monopoly).

No one in the class could really argue against it because as far as monopolies that Google could possibly create, that's pretty minor. A decade later, almost everyone seems to have forgotten that Google did it.

<comment><USER17> What is Hipmunk using underneath?

<comment><USER18> I believe they all use several of the services. I worked at one of the airline booking sites and know they used Sabre and ITA as well as others.

[https://beta.developer.sabre.com/guides](https://beta.developer.sabre.com/guides)

</comment></comment></comment></comment><comment><USER19> This appears to be a time-limited promotion.

> When we predict the price won't decrease for select itineraries booked > between August 13 and September 2, we'll guarantee the price won't drop, and > we'll refund you the difference if it does.

<comment><USER20> When I read that I assumed that they want to observe the effect this guarantee has on pricing by changing people's booking behavior. Doing a time-limited study seems like a good way to do that.

<comment><USER21> I agree, but that seems like such a short window for an accurate assessment.

<comment><USER22> I bet its a "50% of flights" trial, so the data is more comparible.

If they have enough flight bookings per day, even a 1 day trial could be plenty to see how customers behave.

</comment></comment></comment></comment><comment><USER23> My question is, with Google's pretty much non-existent customer service (unless you're on G-suite), how difficult is the process going to be to get to a human if you want to make a claim that they weren't the lowest price?

<comment><USER24> Super anecdotal obviously, but very very difficult. Bought some flights on Scandinavian Air through Google Flights that included multiple checked bags for my wife and I about a year ago. Upon arrival at the airport in Gothenburg, they were very insistent we hadn't paid for bags and had to pay the exorbitant fees for checking bags on the spot.

We essentially could not figure out how to contact anyone at Google Flights to clear up the situation or achieve any form of redress.

<comment><USER25> I don't think it's currently possible to book flights to Google Flights itself. Doesn't it always redirect you to another site to book? You would have to contact that site for help in this siutation.

<comment><USER26> You're wrong, it's possible. [0]

[0] [https://support.google.com/travel/answer/7515668?hl=en](https://support.google.com/travel/answer/7515668?hl=en)

<comment><USER27> Google still isn't the seller of record, though.

> Note: All bookings are made with the relevant airline or online travel > agency.

</comment></comment></comment></comment></comment><comment><USER28> Note that this is a temporary promotion:

> Price guarantee is available between August 13th and September 2nd, 2019. > You'll see the price guarantee badge on select flights where travel is > completed by November 24th, 2019.

Still sounds like a great deal, but this explains why it's not a huge liability.

<comment><USER29> It may be a test run. Flight pricing is complicated, Google may be reasonably worried about the unknown-unknowns.

<comment><USER22> Airlines can easily abuse this guarantee if they want to. The airline can calculate the loss Google would incur through any price change, and they don't necessarily incur the same losses. They can make price changes specifically to make sure Google flights doesn't make money.

This isn't the stock market - flights aren't transferable, since tickets are named.

</comment></comment></comment><comment><USER30> If the airlines know that most of tickets for a flight have been sold via Google, then what's to stop the airlines from drastically dropping the price of the last ticket just to cost Google a ton of money? There's no way this could work if the airlines were in a legitimately adversarial relationship with Google.

<comment><USER31> Even better, have the airlines themselves buy up the tickets via Google. Then drop the price to nearly 0 on the last ticket. Then release the tickets for sale back to the public. Instead of just hurting Google, now, the airline has basically gotten to sell a whole plane's worth of tickets twice.

<comment><USER32> Then sell them back to google again, rinse and repeat until whatever regulatory body with a real hammer gets pissed off.

</comment></comment></comment><comment><USER33> This is awesome, I hope Google doesn't kill it!

Farecast did this and was bought out by Bing to become Bing travel, who then stopped the price guarantees.

</comment><comment><USER34> I use hopper [0] for something similar. But considering google's scale and resources, google might give me more accurate predictions.

[0]: [https://www.hopper.com/](https://www.hopper.com/)

<comment><USER35> I'd be hesitant on that one, or any prediction software, without the backing of the price guarantee like Google has. Otherwise you're really just gambling.

I used to use whatever flight prediction software Bing bought out when I traveled for work. It was pretty accurate most of the time, and I got used to trusting it, but I definitely got burned really badly a few times by continuing to wait as the price sky rocketed under the algorithms assurance that it would drop again before I needed to pull the trigger.

<comment><USER2> Pretty sure it was called farecast.com

</comment></comment></comment><comment><USER36> Some airlines such as Alaska and Southwest already offer this but the pain is monitoring the drops for your fare class etc. If Google is automating that, then more power to them!

<comment><USER9> Google Flights doesn't get pricing for Southwest: [https://www.google.com/flights?hl=en#flt=/m/01cx_.CMH.2019-0...](https://www.google.com/flights?hl=en#flt=/m/01cx_.CMH.2019-08-25*CMH./m/01cx_.2019-08-29;c:USD;e:1;sd:1;t:f)

<comment><USER37> Southwest don't distribute indirectly to leisure travellers, so you won't find them in any booking tool (except corporate travel mgmt solutions)

</comment></comment></comment><comment><USER38> Sounds like Google is trying to dominate one more market. I'm sure they

1) wouldn't mind being the middle man of one more thing 2) continue to transmit travel plans and would be plans to whoever wants to pay.

Google is an advertising and information company.

<comment><USER39> I hope it's not a plain fraud. For a part of my work in OEM industry, I do duties of a professional purchaser, so I know how to get deals.

I had many times such refund and guarantee promises thrown out of the window with explanation "so use us if you want." All kinds of booking agencies being the worst offenders.

One time when I still lived in Canada, I went to a small claims court, and and civil tribunal with "ahem..., commercial contracts are not our jurisdiction"

<comment><USER40> Google is not some small company to commit fraud for a few pennies

</comment></comment></comment><comment><USER41> I recently searched for flights via Google Flights (for Frontier). The price shown for the exact same itinerary was ~$50 more on Google Flights than when I used my smartphone on a different network (disabled WiFi), going directly on Frontier's website. This could be because Google counted for things like, for example, 1 checked bag when comparing all flights.

I don't have enough knowledge on the matter, but I will absolutely use a different device and book directly on the airline's site to ensure I get the best price with no middleman fees.

<comment><USER40> Google flights charges no middleman fee. It definitely would have added a carry on. you can easily remove it

<comment><USER41> I don't know why they wouldn't start charging a middleman fee someday. What other value would they get from building Google Flights?

<comment><USER42> If you get access to someone's travel history, future travel plans, and their purchase habits (luggage weight, how many people you travel with, etc), this information is worth a lot more to an advertisement company than a mere middleman fee.

</comment></comment></comment></comment><comment><USER43> I would never book flight or hotel through 3rd party portal unless there's a substantial discount. Booking direct work better 90% of the time.

<comment><USER44> I feel like that is a recipe for getting price gouged. Or do you search for trips with 3rd party tools and then book it directly?

<comment><USER45> Most airlines show the same price on their site that I find on the aggregators. The exception is multi-itinerary tickets that can save money, but are risky since you are booking separate, multiple tickets.

<comment><USER22> Look around more.

Many aggregators offer big discounts for minor things like logging in or signing up for a newsletter.

$400 off for logging in - sure!

I think they have contracts in place about pricing for non-logged in users (ie. Neither of us will undercut the other). But when you're a customer, they suddenly offer much better deals. Yes I will take the 'loyalty bonus' of free extra 5 days stay for booking a weekend - thanks!

Some of the aggregators are so desperate to get customers that they will give you something for $0. I rented a car for a week for $0 through easyrentcars because I signed up through a refer link for example.

</comment></comment></comment></comment><comment><USER46> How often do prices actually drop? I fly pretty often and I can't remember the last time I encountered a price drop on a flight over time.

<comment><USER47> The flight I want has been fluctuating between $400 and $700 every couple of days for the last two weeks. It's $729 now and I need to gamble on whether it will go back down and I should wait, or whether it's about to go up even higher.

I _hate_ flying solely because of the gambling mechanic built-in to the purchase.

<comment><USER46> It is an international flight that's 6+ months away? And the exact same flights (not just same days etc) Because that's the only time I can remember seeing something like that.

<comment><USER47> It's USA to Canada in less than 2 months.

<comment><USER48> I was thinking it might be a domestic Canadian flight. The high average price and high variability fit the standard pattern for our domestic flights as well.

</comment></comment></comment></comment></comment><comment><USER49> That's ridiculous, if they had an AI that could accurately predict prices, they would quickly become one of the largest, most powerful corporations in the world.

Uh, wait ...

<comment><USER50> The profit from accurately predicting future prices would dwarf advertising / computing revenue. The problem with any prediction is as soon as it's acted on or made public it starts to affect the system requiring an updated prediction. If enough people buy into the prediction it's a self fulfilling prophecy. So much of pricing is influenced by human nature though. Good luck predicting that consistently over time.

<comment><USER51> Also, the airlines could change their algorithm - randomly. If for no other reason than to muck with Google.

<comment><USER52> From their detail page:

> How much money can I get back? Price guarantee pays you the difference > between the flight price when you book and the lowest ticket price. To get > money back, the price difference must be greater than $5. You can receive up > to $500 back total for all of the flights you book with Google price > guarantee.

That'd be pretty hilarious for an airline to explicitly dick them over for $500 a pop.

<comment><USER28> Somehow I think Google would manage to outsmart them at their own game.

</comment></comment></comment></comment></comment><comment><USER53> "and notify you when we predict the price may go up soon or won't get any lower"

This feels like a different version of only 3 seats left or only 2 rooms available at this price. Why not notify me when the price goes down or is likely to go down?

</comment><comment><USER54> Flight prices shown in India by Google are always been higher than other booking sites. Never heard of anyone around booking flights through Google here.

<comment><USER42> I mostly blame the lack of Integration with reservation systems in certain carriers like Indigo, Nepali Airlines, Air Asia, etc. Then there is a whole range of smaller carriers (including Nepal's numerous airlines). Some airlines are downright now searchable through any means other than the airlines own web site.

</comment></comment><comment><USER55> Does that mean that they'll offer a full refund if your travel plans change, since tickets get more expensive closer to the day of the flight anyway?

<comment><USER56> I very much doubt it. Those would be new tickets, not a changed price on existing ones.

</comment></comment><comment><USER37> I believe there was a startup that offered this as a paid service, using some sort of price prediction algorithm

</comment><comment><USER57> TANSTAAFL. What is the catch of using Google Flights? What would Google do with this data?

</comment><comment><USER58> Hmm. Interesting move with all the antitrust sentiment floating around. Google has certainly focused their "everything above the fold is us" approach heavily on travel. Don't believe me? Do a few travel related queries and see how much above the fold IS NOT google. They have been VERY aggressive in this area.

</comment><comment><USER59> Is this the next industry taking a hit from an asset-light strategy?

</comment><comment><USER60> Seems like it will apply to such a small subset of flights (that are already probably higher than you'd want because they're soon).

There is no way Google is going to guarantee if there is a potential sale window from the airline.

</comment><comment><USER61> US-only, of course.

</comment><comment><USER62> And please don't show 737s.

</comment><comment><USER63> Well, this is boring. I would prefer an insurance that locks in the price for some time. dohop.com was offering this for some time.

<comment><USER64> Forecast was doing that, quite successfully (115 m$ exit).

</comment></comment><comment><USER65> Do more business with Google? Hard pass.</comment>


Puzzle HN: 100 prisoners, 100 boxes... - <AUTHOR> There are 100 prisoners and a sadistic prison warden. The warden has 100 boxes labeled 1-100, in which he randomly distributes 100 pieces of paper. Each prisoner's name is written on one and only one piece of paper.
The warden says to the prisoners: "You may each open any 50 of these boxes that you choose. If all 100 of you find the box with your name in it, you may all go free. If any of you fail, you will be imprisoned forever." He tells the prisoners that they may agree on their strategy beforehand, but that he will choose them to enter the room in a random order, and they will not know anything about the previous prisoners' experiences ahead of time. They cannot move the paper around between boxes.
What are the best odds the prisoners can give themselves? (Hint: it's better than 1/2^100.)
Bonus question: in the limit as the number of prisoners goes to infinity (and correspondingly, the number of boxes), what value do the optimal odds approach? <comment><USER2> Some clarification:

Each prisoner finds the room in the same state as each other. After opening the boxes they are subsequently closed again before the next prisoner. I believe this was intended to be inferred from:

         ... they will not know anything about the
         previous prisoners' experiences ahead of time.

Hint - the probability of success is greater than 10%.

There is a modification of the "obvious" solution that even works if the warden knows the prisoners' strategy beforehand and behaves in a maximally pessimal (from the prisoners' point of view) manner.

<comment><USER3> I can see that the prisoners can do better than 1/2^100, but I don't see how they could get anywhere close to 10% success - so I must be missing something big here.

<comment><USER4> I've looked up this puzzle elsewhere and it is described as allowing the prisoners to manipulate the contents of the boxes they open to a limited degree.

<comment><USER2> There is a way of doing this that does not require doing so. The places you have looked up might have described a weaker version of the puzzle.

<comment><USER4> Thanks for the clarification.

Could you post a link to the solution? Or post it as a ROT-13 comment? Otherwise I might never find out the answer!

<comment><USER2> email me - address is in my profile.

In return, consider this: <http://news.ycombinator.com/item?id=1891084>

</comment></comment></comment></comment></comment></comment><comment><USER5> Late in the day hypothesizing here.

As the boxes are random, and the order is unknown, and there is no hidden information passed between each prisoner, and the room is reset each time - the only controllable factor the prisoners can agree on ahead of time is the strategy for which boxes each one will open.

Given the boxes are already randomized, using a random order is no more useful than using a sequential order.

So assuming they know the layout of hte boxes (is it 100 in a line or 100 in a square... presumably this can be figured out or some other strategy accounted for so everyone approaches things the same way) - each person opening 50 boxes has the same odds of finding their name. To maximize the odds of the entire GROUP finding their name, we need to ensure that each box is opened the same number of times by the end of the exercise. As we can't pass any information back and forth, this is the best we can do.

First 50 people open the first 50 boxes. Second 50 people open the second 50 boxes.

Or - as they may or may not know their position - they only need a strategy that ensures that each box is opened an equal number of times by the end.

To me that still looks like (1/2)^100..... which by definition isn't the answer - so I'm missing something. Eager to see the answer.

<comment><USER2>
      > To maximize the odds of the entire GROUP finding their
      > name, we need to ensure that each box is opened the same
      > number of times by the end of the exercise.

You were doing really well up to this point, but this doesn't follow.

</comment></comment><comment><USER6> The first prisoner opens 50 and sorts the 50 in alphabetical order (in an obvious manner). The second prisoner, upon seeing the sort, can quickly see if his name was in the original 50 (My name is Evan, I should be before Henry and after Bobby, etc). If he finds it quickly, he has plenty of "openings" to help sort the remaining boxes (maybe in a second row behind the first).

The rest of the prisoners should be able to easily find their names within 50 trials.

Success rate is PRETTY close to 50%.

<comment><USER7> The boxes' states are restored after each prisoner leaves the room, so there's no way to sort them. The ideal solution would actually work even if the order of the boxes was shuffled each time.

</comment></comment><comment><USER8> I think you messed up the formulation of the problem. As stated, a strategy would be \- first prisoner opens 50 boxes. \- second prisoner opens the other 50. \- each prisoner finds the box with the paper with his name on it.

Success rate: 100%. There probably are other constraints but I can only guess at them (do they visit the room one by one, and must they decide on a box to choose before leaving? Who can talk to whom? Must they close all boxes before leaving the room?)

<comment><USER2> I believe the statement as made is correct, although not necessarily as clear as it could be.

For example, your suggested "strategy" is wrong - the first prisoner as you've stated only has a 50% chance.

Further, after each prisoner the boxes are closed so that each prisoner finds the room is exactly the same state, with no communication between them.

<comment><USER8> Apparently, my formulation isn't as clear as it could be, either :-)

My 'solution' has all of the prisoners point out 'their' box after the second one has opened the last 50 boxes.

As to the 'no communication between': if there is no communication, it seems each of them cannot do better than 51/100 (50 opened boxes, and if their name isn't there, a 2% gamble)

However that isn't true. Suppose the first 51 each open the first 50 boxes and decide to choose the 51st box if they do not find their name, Then, all others, working under the assumption that the first 51 found their name (if they didn't, the game is lost anyways), can just open the last 49 and be certain to find their name.

That would bring the probability to about 2^-50. I doubt that is the optimal strategy, though. There seems to be much more room between 1/100! and 0.01^100.

<comment><USER2> I still, really don't understand what you're suggesting. Let's go carefully.

The first person opens 50 boxes. Let's suppose they find their own name (otherwise we're dead anyway). They leave the room, everything is put back exactly as it was, they're not allowed to communicate with the others.

It seems to me you're suggesting the next person opens the second batch of 50. OK. But then they leave the room, everything is put back exactly as it was, and they're not allowed to communicate with the others.

What does the third person do? They're confronted by 100 closed boxes with no idea of anything, except that the first person's name is in the first 50 boxes, and the second person's name is in the second 50 boxes.

So, what now?

<comment><USER8> The word 'close' does not appear in the problem formulation at all. Apparently, we must deduce that all boxes get closed between visits from " _they will not know anything about the previous prisoners' experiences ahead of time_ ". I am OK with that, but I still do not think it is a clear way to describe the problem.

So, ignoring that IMO fairly implicit message, the 'answer' I proposed is: prisoner #1 opens 50 boxes, prisoner 2 opens the other 50, and then each prisoner trivially searches for his name.

Nitpicking the text further: what is that _ahead of time_ doing there? What time? What can they learn afterwards?

<comment><USER2> I can't decide if you're trolling, or genuinely don't understand. This is becoming like explaining a joke, and turning into and endless sequence of refinements.

I'll answer you once more. If you don't get it after that, I don't really care.

      > The word 'close' does not appear in the problem
      > formulation at all

No, but "open" does. The implication is that the boxes each contain a piece of paper on which exactly one name is written, and that each box is closed.

      > the 'answer' I proposed is: prisoner #1 opens 50 boxes,
      > prisoner 2 opens the other 50, and then each prisoner
      > trivially searches for his name.

You are assuming that the boxes can be left open. That is ruled out when the puzzle says:

      > and they will not know anything about the previous
      > prisoners' experiences ahead of time.

If the boxes remain open then, specifically, the second prisoner will know the names that have been seen by the first prisoner. That's not allowed.

      > Nitpicking the text further: what is that ahead of
      > time doing there? What time?

The time that they enter the room.

      > What can they learn afterwards?

If, for example, their strategy is that everyone opens the first box (which is pretty pointless, but this is just an example) then easch one will learn something about what the others knew. In this way they know things that the prisoners before them knew.

There are puzzles where this is significant. I'm not going to tell you if this is one of them.

I feel that your objections to the wording are very like the programmer who insists on more and more refinements to a specification, and eventually just transliterates the spec into code. Anything that can't be trivially transliterated is queried, until finally the specification is isomorphic to the code.

My apologies if I'm doing you a disservice, but I find it very difficult to find a position from which your questions become reasonable, and I offer answers and explanations in an attempt to learn more. Currently I'm failing, and perhaps it's time to give up.

<comment><USER8> No, I am not trolling. My initial remark (very early in this thread) was just that the formulation wasn't clear to me. I thought that might trigger a rewording that would help later readers. After that, I just answered questions about why I found (past tense!) it not clear. I also think I made clear that I do understand the problem:

      *Apparently, we must deduce that all boxes get closed between visits from "they will not know anything about the previous prisoners' experiences ahead of time". I am OK with that,*

but I guess I should have been even clearer. It may seem nitpicking, but to solve this, I need two things:

        - an understanding of what the problem is.
        - a solution to the problem.

I find it natural that, getting stuck at step 2, to revisit step 1, looking for something I missed on reading it first (Quoting Polya: 'What is the unknown? What are the data? What is the condition?'). When I did that, I started to wonder what the description tried to say. Since the trivial answer that I gave in my initial reply, I did get that, but it didn't exactly jump out to me.

Thanks for the polite replies, but let's close this discussion. It is helping neither of us.

[D _mn: initially, I thought "of course the probability is way better than (1/2)^100'. There are only 100! permutations to choose between", but rereading the problem once more I begin to wonder whether_ 'in which he randomly distributes 100 pieces of paper'* actually implies that each box receives one piece of paper. Please don't reply, or I may feel obliged to apologize again.]

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> Found the solution here:

[http://www.sciencenews.org/view/generic/id/7649/title/Puzzli...](http://www.sciencenews.org/view/generic/id/7649/title/Puzzling_Names_in_Boxes)

<http://ocfnash.wordpress.com/2009/12/12/pity-the-prisoners/>

Warning: Don't spend hours of lateral thinking trying to solve this puzzle unless you have a degree in mathematics.

<comment><USER7> You don't need math skills to solve this, only problem solving skills. There are only so many ways to systematically choose 50 boxes from 100 when the only information is a name on the inside and a number on the outside.

<comment><USER4> I'm just trying to help people that might spend an hour looking for a simple kind of solution to this, when the answer is really quite complicated and the math involved in the linked solutions are way beyond the understanding of most non-mathematicians.

<comment><USER2> I've explained it to many non-mathematicians, and they certainly seemed to have understood.

<comment><USER4> Even the first solution linked to doesn't explain it. It only declares the result that the probabilities work out in a particular way.

The second link contains the math, and no way would a non-mathematician have been able to come up with that math.

<comment><USER3> Here's another link that explains it pretty well without using any fancy math:

<http://www.mast.queensu.ca/~peter/inprocess/prisoners.pdf>

edit: I agree that this does involve some math, but I like that it all can be derived from basic principles of probability.

<comment><USER4> That explanation is not consistent with the claim

 _You don't need math skills to solve this, only problem solving skills._

I'm just saying, it'd be nice if there is a warning when something that looks like a standard lateral thinking brain teaser is actually the topic of a paper submitted by a pair of professors of mathematics to the 2003 Conference on "Compexity".

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> So if I understand this correctly, once the prisoners start opening boxes, there is no communication allowed between them, right?

<comment><USER7> Correct, and after each prisoner goes, the boxes are restored to their original state.

<comment><USER3> I'm going to post my current thinking on this, in the hopes that maybe someone can give me a hint without revealing the whole solution:

It seems to me that the best that the prisoners can do is 1/2^50 (and the worst they can do is 0). For instance, if the prisoners decided that everyone would just open boxes 1-50, then they would have zero chance of finding all 100 names (since 50 of the boxes would never even be opened). It seems like the best they can do to maximize their chances is to make sure that each box is tried exactly 50 times. One way to do that is to divide the prisoners into two groups of 50, then assign the first group to boxes 1-50 and the second group to boxes 51-100. Then the chances that the first group all find their names is 1/2^50 (not 100% sure about this number, but it seems reasonable) - and if the first group all find their names, then the second group will too (since if all 50 in the first group were found in boxes 1-50, then all 50 in the second group must be in boxes 51-100). So the total probability of success is 1/2^50.

What's wrong with this?

<comment><USER2> The number isn't exactly right, but the reasoning is broadly right. That number is still unreasonably small, and nowhere near what can be achieved.

<comment><USER3> OK, I gave up and looked at the answer. Pretty amazing. Just out of curiosity, why isn't the probability of my solution equal to 1/2^50?

edit: I think I found the answer: it should be equal to (50!)^2/100!, right? Now, how to decide if that's smaller or larger than 1/2^50?

edit: Awesome! thanks for the answer.

<comment><USER2> Because if the first person succeeds in finding their name in the first half it then makes it less likely for the next person to find their name there. Once the first 49 people have found their name in the first half, there's only a 1/51 chance that the last person will.

It's late and my brain has turned off for the day, but it's something like this ...

Arrange 100 people, and ask in how many ways the first 50 are in the first 50 places. There are 50!.50! ways of arranging things with the first 50 first, and the others next. That's out of 100! arrangements in total.

So you get 50!50!/100!

You can evaluate that approximately by using Stirling's approximation: n! ~ (n/e)^n.sqrt(2.pi.n). The answer is about sqrt(100.pi)/2^100.

Probably. Too tired to check it. Follow the reasoning and check that, not the answer.

</comment></comment></comment></comment></comment></comment><comment><USER9> Easy, first prisoner randomizes the order of the boxes, opens and sorts the first 50 boxes, hoping to find his name. Chance 1 in 2

Next prisoner uses a binary search to find his name in the first 50. Should have to open 6 boxes (log2(50)), if he finds it in the first 50 great. Either way he then sorts the next 44 boxes. Chance around 88%

3rd prisoner sorts the remaining 6 boxes, and finds his name in one of three piles using binary search. Chance, 100%

All remaining prisoners can use a binary search. log2(50) + log2(44) + log2(6)

I don't know how to integrate the 50% -> 88% chance, I'd estimate the answer to be around 44% based on my gut.

If the prisoners don't know the order they enter the room then they should each turn the first unturned box sideways to communicate the state of order. eg. if the first box is turned sideways you are prisoner #2.

I don't know if this is a brain teaser or just asking how to calculate the chances of 1/2 50 times in a row. (eg. the probability of correctly predicting 50 coin flips in a row)

<comment><USER5> The boxes are closed and each person enters the room in the exact state as the previous one, with no knowledge of what the other person found.

I'm not seeing how a binary search will help you find your name in a randomized set of names - there is no order to work from to perform the search.

</comment></comment><comment><USER10> The answer you think you have to this it outside the bounds of the question you gave. Re-phrase the question honestly. The answer is .5^100. I am sorry, you will have to allow more power on the prisoners parts, perhaps the ability to label things.

<comment><USER2> Unless I've misunderstood you, you are wrong.

<comment><USER10> Well, you insist there was no communication, but all solutions I can find that yield a probability you describe involve communication. Exemplar being that each box itself is labeled by a name. Each prisoner starts at the box with their name and reads the slip inside. following a chain of names until they reach their name. The flaw is that this solution violates the premise, the convicts will have knowledge about how the other convicts acted (similar to how they did, otherwise the system fails), which directly violates the premise.

</comment></comment></comment><comment><USER11> Isn't this problem a more complex version of the Monty Hall Problem? (<http://en.wikipedia.org/wiki/Monty_Hall_problem>).

<comment><USER2> No.

</comment></comment><comment><USER2> I know this, but I won't spoil it for those who don't. It's a staple in some circles I frequent.

<comment><USER12> Is the wording completely correct?

<comment><USER5> Seem so - I haven't worked out the math yet - but remember the goal here isn't "waht's the guaranteed winning strategy" - because there isn't one. Odds are everyone is doing prison for life - but there is an optimal strategy that's better than it might seem at first that the group could use to at least reduce their odds of life in prison.</comment></comment></comment>


Docker for Windows won't run if the Razer Synapse management tool is running - <AUTHOR> https://twitter.com/foone/status/1229641258370355200 <comment><USER2> The risks of blindly copying a solution from Stackoverflow.

In 2009, someone posted a buggy solution on Stackoverflow, and took 3 years to fix the bug. In the mean time, a few applications had incorporated that bug, trusted the Stackoverflow answer blindly, and failed to test it properly.</comment>


Elon Musk aims to revolutionise battery technology - <AUTHOR> https://www.bbc.co.uk/news/business-53067009 <comment><AUTHOR> Batteries in the grid are the key to enabling renewables to accommodate fluctuating demand -plus- it creates an endless market for used car batteries once their storage capacity drops too far to efficiently drive around on top of, recovering a substantial part of the cost, thereby reducing the TCO for Tesla owners.

Big, smart long-game play that, for me, explains the stock price.</comment>


Ask YC : Review my start up whollhelpme - <AUTHOR>

Check it out at www.whollhelpme.com<p>A question and answer site which is free, fast and simple. Enabling users to post questions and get answers without any banners, pop-ups and blinking glitz to disturb. <comment><USER2> Clickable: <http://www.whollhelpme.com>

<comment><AUTHOR> Thanks famfam

</comment></comment><comment><USER3> who'll is a really really awkward word...any other domain options while it's still early?

<comment><AUTHOR> Thats the best i could come up with ddemchuk. Any other domain suggestions are welcome.</comment></comment>


Revisiting 64-bit-ness in Visual Studio and elsewhere (2015) - <AUTHOR> https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere/ <comment><USER2> At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of out-of-memory error, and more often than that, it slows down to a crawl because it has to garbage collect every few seconds in an attempt to keep its memory usage below this magic limit. Even though the machine has 20 GB of free RAM that Visual Studio just can't use.

The author acknowledges that this can happen:

> So, you're now out of address space. There are two ways you could try to > address this.

> a) Think carefully about your data representation and encode it in a more > compact fashion

> b) Allow the program to just use more memory

> I'm the performance guy so of course I'm going to recommend that first > option.

As a "performance guy", he should know that using a bit more RAM is essentially free, and much, much easier to code than doing the kind of bit- fiddling wizardry he suggests ("encode it in a more compact fashion"). In practice, that kind of low-level code will not get written anyway, at least not by modern Microsoft, and much less so by most extension authors. Which means that there's an arbitrary and very hard limit on how much you can customize/extend Visual Studio before you hit that 3 GB wall. And again, this is on modern workstation machines with gigabytes of unused RAM lying around.

In short, there may be very valid technical reasons why VS can't go 64-bit, but to claim that this doesn't hurt the product is in my opinion not justified.

<comment><USER3> Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.

<comment><USER4> Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.

<comment><USER5> I really hope it is. I don't really find VS Code to be any slower than VS. Of course, this depends on what you're using each for. I find I prefer VS Code because it has so few default features. The default install does not contain GB of bloat that I will never need. I'm able to build the experience I want, rather than fight one thrust upon me.

<comment><USER6> "I don't really find VS Code to be any slower than VS."

Given VS Code has a fraction of the features VS has, it should be noticeably faster. It will eventually be GB of bloat and slower than VS.

What I'd like to see instead is features being broken out into separate components that can be used by any other editor/tool. Of course, if every component is going to required it's own dot file in my home directory to (maybe) turn off telemetry, I won't touch it, so I'd rather see those things developed by someone other than MS.

<comment><USER7> You have a very different experience with VS than I have... right now, I'm waiting half an hour, so I can check out a branch from vsts, so I can wait another 6-8 minutes to build my solution, etc... it's painfully slow... VS Code, edit, next...

I've only seen VS Code run slow if you're running on 2gb of ram, or have hundreds of competing plugins installed, and even then. VS Code is way better than VS proper from my own subjective experience.

</comment></comment></comment></comment></comment></comment><comment><USER8> I remember his original post back in 2009 and being very unsatisfied.

I wanted the 64-bit transition only so I could properly use my tools at work (used to work in a .Net shop). We had resharper and several other plugins that ran in the same Visual Studio process as everything else and it was fairly common to hit the memory limit of a 32-bit process and Visual Studio would essentially die until it was killed and restarted.

Sure, you can say "stop using those tools" or "they should have written them better". But at the time I was required to use most of them (it wasn't only Resharper though Resharper was pretty nice).

Today I don't have this problem anymore. But I think because of that type of issue it would still likely be worth it. Honestly I feel like they could optimize Visual Studio at the same time; it has a ton of capability but it's also incredibly large and, from my understanding, carries a TON of legacy code and resources throughout.

<comment><USER9> I guess his original point was that while moving to 64 bit would help the few users who actually hit memory allocation limits, it would _also_ be a monumental effort for a project the size of Visual Studio to do so, including out-of-process support for 32-bit extensions to maintain compatibility, probably rethinking designers and debugging along the way. And all that to make things actually _slower_ and taking _more_ memory for everyone. His argument wasn't entirely »Stop using those tools while we do nothing at all«. It was »They should have done the right thing, but we'll also work towards making Visual Studio take less memory«. Especially considering that not leading everything you might eventually ever need at once in the beginning has probably a much smaller compatibility impact than upgrading significant parts of the IDE.

</comment></comment><comment><USER10> This is a pretty myopic view of performance and 32-bit code.

\- You really only get 3GB of RAM

\- Actually, you get less than that, because of DLLs that get loaded into that space.

\- Actually actually, fragmentation becomes a problem, and making very good use of the remaining memory gets awkward pretty quickly.

3GB is pretty crowded, especially when you're talking about (say) a game with tens of GB of footprint. You need to page stuff into that footprint, and be clever about the memory pressure not affecting the user experience.

On the server side of things, we regularly run processes with > 8GB footprints, including things like solr (at 32 to 160GB). Breaking this stuff up would involve a lot more disk and network chatter, as well as bugs involving OOM conditions, reducing global performance and reliability.

So while VS may be fine with 32-bit code+data (I am not convinced), real-world applications definitely need more. I'm guessing that making a 64-bit VS is hard for legacy reasons, and that the 32-bit space is actually holding the VS team back (and possibly plugin makers as well).

<comment><USER11> > So while VS may be fine with 32-bit code+data (I am not convinced)

Many people in this thread and the corresponding one on reddit report VS regularly crashing on OOM or eating all the CPU garbage-collecting nonstop as it gets closer and closer to the limit.

</comment></comment><comment><USER12> In my experience, Visual Studio performance has improved significantly since VS2010, but if you compare it to VC6, it's a joke. There's still an old PC at the office running it, and double clicking a project opens the IDE and loads the project in less than a second. It's beautiful.

<comment><USER13> Couldn't you say this about the software industry in general? In the 90's I used to have a Sun workstation on my desk. It ran the powerful Solaris operating system, but had just 16MB of RAM! Today you need 1GB of RAM to run an OS comfortably. My question: what does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?

<comment><USER14> Well, I don't know, could your Solaris (mostly) seamlessly connect and disconnect to wireless networks? I don't even think there were that many wireless networks in the world back then :)

Anyway, this is is just 1 contrived example of something modern OSs do, and that OSs from the 90's didn't do.

Sure, there's some bloat, but a lot of it is the "Mozilla kind": "Mozilla is big not because it is full of useless crap. It is big because your needs are big".

<comment><USER15> Isn't a significant chunk of OS memory usage caused by the desktop UI? If we're talking about servers, I'm guessing it would be because of drivers and more built-in functionality, some of which is rarely used.

<comment><USER16> Yeah — the image buffers (screen resolutions) are bigger, we run more apps, more advanced desktop environments… also in the old days (before OS X, Compiz (fun with desktop cubes!) and Vista Aero) people used to run without compositing, which meant one common image for all apps to draw into.

Just booted my laptop (FreeBSD -current amd64, 1366x768 display) and started X: only 204M "Active" memory. Of the 204M: 60M is syncthing, 39M compton, 31M Xorg, 11M i3bar, 11M polkitd, 10M i3, 9M dunst, 5M wpa-supplicant… Not counting syncthing that's 144 megabytes. I think that looks reasonable. You can go lower and optimize for low memory (no polkit, no compton — 94M) or go higher and optimize for usability and fancy UI features (install gnome :D)

</comment></comment></comment></comment></comment><comment><USER17> I might be wrong, but aren't there much more registers available in 64 bit mode on intel? That potentially outweighs any memory increase because it can reduce cache pressure. Or is this mostly alleviated by register renaming and other tricks?

<comment><USER11> > I might be wrong, but aren't there much more registers available in 64 bit > mode on intel?

It's not "intel", it's x86. x86_64 has twice the number of registers.

<comment><USER18> > x86_64 has twice the number of registers

The "typical ALU instructions" as add, cmp etc. can now encode 16 registers instead of 8. But the FPU stack still has 8 entries to encode and there are also still only has 8 MMX registers in 64 bit mode (they overlay the FPU stack as you surely know).

On the other hand with AVX-512 there will be 32 xmm/ymm/zmm registers available instead of 8 in 32 bit mode (4 times).

UPDATE: On the other hand in 64 bit mode there are only 2 segment registers available instead of 6 in 32 bit mode (OK, the 4 common ones were (IMHO unjustifiably, since there are some cool things that you can use them for if you know what you do) not used in modern 32 bit OSes (Windows NT, Linux), so they were left out).

TLDR: The multitude depends on the type of register that you consider.

<comment><USER19> The FPU stack is only 8 entries in x86-64, yes, but the 128-bit SSE float/SIMD register set was indeed expanded to 16 entries, just like the GPRs (rax, rcx etc). The FPU stack is legacy and is barely used anymore, instead most floating point operations are done with SSE instructions.

<comment><USER18> > The FPU stack is legacy and is barely used anymore

I know that if you implement an algorithm via SSE/AVX it typically is much faster than if you use the FPU. But I still believe that the FPU has its uses: For example it also supports 80 bit precision floating point numbers, while SSE/AVX only support 32 or 64 bit ones. There are applications where this capability can be quite useful. This is one reason why the FPU is still supported (and sometimes used) in 64 bit mode.

<comment><USER19> Yes, it has its occasional uses and is still supported, but the point is that x86-64 got a noticable FP capability boost through the doubling of the SSE registers compared to 32-bit x86. SSE is not just for SIMD, it has single/double scalar instructions as well, which mostly replace the old FPU.

If you look at generic floating point code generated for x86 by any modern C/C++ compiler, you won't see any FPU use, it's all SSE scalar, and occasionally SIMD for clever compilers.

</comment></comment></comment></comment></comment></comment><comment><USER20> I really wish MSFT would support the x32 ABI[0]. While having a single amd64 ABI, compared to 6-7 active in the x86 days, has its advantages, MSFT already threw it away with vectorcall. And x32 is arguable more useful than vectorcall.

[0]: [https://en.wikipedia.org/wiki/X32_ABI](https://en.wikipedia.org/wiki/X32_ABI)

<comment><USER18> An ABI for amd64 was consciously developed independently by the gcc developers and Microsoft. Microsoft did "the obvious thing" and extended __fastcall to define their ABI.

Here are links about this topic:

> > [http://stackoverflow.com/a/35619528/497193](http://stackoverflow.com/a/35619528/497193)

> > [http://stackoverflow.com/a/4438515/497193](http://stackoverflow.com/a/4438515/497193)

> > [http://stackoverflow.com/a/35621290/497193](http://stackoverflow.com/a/35621290/497193)

</comment></comment><comment><USER21> Would he have made those same comments to resist going from 16 to 32 bit?

Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

<comment><USER13> No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit. This problem went away with 32 bit. Adding more bits beyond 32 does not bring proportional benefits because the numbers we deal with fit in 32 bit.

<comment><USER16> "the numbers we deal with fit in 32 bit"

Except when they don't. Everyone already forgot tweet number 2147483648? :) [https://techcrunch.com/2009/06/12/all-hell-may-break- loose-o...](https://techcrunch.com/2009/06/12/all-hell-may-break-loose-on- twitter-in-2-hours/)

</comment></comment></comment><comment><USER22> _Disclaimer: I don 't know too much about this field_

Can someone explain why exactly 64-bit is generally slower than 32-bit?

I understand that more RAM will be used and I/O to it slowed down due to double the bits pushed around since "chunks" have double the length, which ends up being a lot of empty padding (is that correct?).

But everything _inside_ the CPU, like registers or ALUs, are 64 bits wide anyway (right?), so computing in 64-bit mode would just make use of resources that were unoccupied in 32-bit mode. Or am I missing something?

<comment><USER23> Because no one else has mentioned it, paging is more expensive in 64-bit. In 64-bit, the kernel uses a 3 or 4 level page table requiring 3 or 4 SDRAM accesses on a TLB miss. 32-bit kernels can get away with 2 SDRAM accesses (PDE+PTE) if they're doing 32-to-32 translation. On a ~3GHz CPU, each uncached SDRAM access will cost the CPU about 200 cycles which means a worst-case 32-bit scenario would be about 400 cycles but 64-bit could reach +800 cycles.

This only applies to running a 64-bit kernel vs a 32-bit kernel; running a 32-bit process on a 64-bit kernel will incur the same page table cost as a 64-bit process.

<comment><USER24> Exactly, and I seriously doubt that in 2017 anyone is using a 32 bit OS with visual studio (I had to endure it in 2015 at work and I know very well what it means)

<comment><USER23> Agreed. And, while I have no evidence of this, my intuition is that the extra GPRs you get in 64-bit more than makes up for any minuscule system-wide performance hit 64-bit long-mode paging imposes.

</comment></comment></comment></comment><comment><USER25> Security can improve with 64-bit as well. It's a lot harder to break ASLR in a 64-bit address space than a 32-bit one. Though again, that might not apply to VS where a user can get "arbitrary code execution" by design.

<comment><USER15> That's assuming high entropy for address randomization of course. A 64-bit OS that has a weak ASLR implementation could end up weaker than a 32-bit OS that implements ASLR correctly. Your point definitely stands if both are well made.

</comment></comment><comment><USER26> 2016 follow-up from the same "I regret I did this" person

[https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit- vis...](https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual- studio-the-pro-64-argument/)

</comment><comment><USER27> I only have VS2010, but I always felt that VS stacked up pretty well against the competition, performance-wise. Eclipse always seemed painfully slow, and Xcode hasn't really impressed with its performance. That's no reason to rest on your laurels, surely. But at least VS shows some evidence of restraint in abusing resources.

<comment><USER28> The big perf drop in VS was between 2013 and 2015 when Roslyn was introduced (not sure if that's the reason though). It has improved somewhat in 2017 but I still find 2013 to be significantly faster than 2017.

</comment></comment><comment><USER29> "Because virtually invariably the reason that programs are running out of memory is that they have chosen a strategy that requires huge amounts of data to be resident in order for them to work properly. Most of the time this is a fundamentally poor choice in the first place. Remember good locality gives you speed and big data structures are slow. They were slow even when they fit in memory, because less of them fits in cache. They aren't getting any faster by getting bigger, they're getting slower. Good data design includes affordances for the kinds of searches/updates that have to be done and makes it so that in general only a tiny fraction of the data actually needs to be resident to perform those operations. This happens all the time in basically every scalable system you ever encounter. Naturally I would want people to do this.

...In the VS space there are huge offenders. My favorite to complain about are the language services, which notoriously load huge amounts of data about my whole solution so as to provide Intellisense about a tiny fraction of it. That doesn't seem to have changed since 2010."

But I'm sure that by remaining 32-bit, in another 5 years maybe everyone will magically optimize their stuff... Any second now...

</comment><comment><USER30> The JVM has a neat trick where it uses 32 bit pointers up to 32GB heap sizes, because alignment is 8 bytes and so there are really only 1/8th distinct possible memory adresses for the whole adress space, so you can just easily map them.

Is this something VS could do?

</comment><comment><USER31> tl;dr... its humongous task and we are busy adding more "instant azure buying- options aka deployment tools", it will only benefit 1% of our users and we also want to keep milking this cow until the shit hit the fan.

</comment><comment><USER32> When I'm working on performance, I measure twice and cut once. I know measuring is 'hard' as there's a lot of code optimised for x86 in VS, but saying 'It would be slower built for 64 bit' is cutting before measuring even once.

I have the greatest of respect for the author, but everyone needs to be exposed to 'trust, but verify' at least occasionally, just in case they happen to be wrong this once.

</comment><comment><USER33> I don't see the point of this article. The VS team has moved more and more stuff out-of-process. VS 2015 can easily use more than 4 GB (if you're working in medium to large solutions), but it's divided up across 3-4 main processes. MSBuild processes (normally 1 per thread) are also staying around for 15 minutes now, so they can be reused.

<comment><USER34> Where it falls down is if the debugger tries to load more than 3GB of symbols. Guaranteed crash every single time. You can manually limit the symbols it loads - but that doesn't apply to other parts like the profiler which will still crash deterministically.

</comment></comment><comment><USER35> The author seems to be defensive, trying to justify the status quo. I would be interested what the real reasons are. Why have most other Microsoft products moved to 64bit but VS was hesitant from the beginning?

</comment><comment><USER26> "The one who wants - seeks ways, who does not want - seeks a reason"

<comment><USER36> That's pretty apt. There are _always_ legitimate reasons why doing something is difficult and imperfect, but there's a really clear future here. It's absurd to think that Visual Studio will remain 32-bit in 10 or 20 years' time.

And no, as any C++ developer will tell you, the answer is not to move to a souped-up text editor (Visual Studio Code).

</comment></comment><comment><USER37> I remember people favoring the use of their 32bit JVM instead of the 64-bit one for performance reasons but didn't wondered why.

Makes sense if you're running Java with -Xmx1024m

<comment><USER38> When reading about Elasticsearch I was fascinated to learn that the JVM can often use 32-bit object pointers to address about 32GB of RAM when running in 64-bit mode: [https://wiki.openjdk.java.net/display/HotSpot/CompressedOops](https://wiki.openjdk.java.net/display/HotSpot/CompressedOops)

<comment><USER39> As someone who comes from the .NET world, this is something that pissed me off about configuring Java applications like Elastic.

If I've got a box with 512GB of ram, it seems I'm supposed to spin up multiple instances to satisfy this, all because the JVM has a hissy fit if you go over ~30GB. This then means worrying about replication and ensuring we don't have both the primary and replicas sitting on the same box.

It seems insane that this is an actual issue in 2017.

<comment><USER18> > If I've got a box with 512GB of ram, it seems I'm supposed to spin up > multiple instances to satisfy this, all because the JVM has a hissy fit if > you go over ~30GB.

What is the actual technical reason why the JVM cannot (easily?) address more than 32 GiB of RAM?

<comment><USER39> The ES documentation goes into more detail on this.

[https://www.elastic.co/guide/en/elasticsearch/guide/current/...](https://www.elastic.co/guide/en/elasticsearch/guide/current/heap- sizing.html)

<comment><USER18> Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER40> Right now, I'm fighting with: "fatal error LNK1248: image size (1004CB720) exceeds maximum allowable size (FFFFFFFF)" :-(

<comment><USER41> You will have to split up your library.

There is also a limit for PDB files of 1GB, which can be workarounded to 2GB, but from the error above I think you are not hitting this limit.

<comment><USER40> Thanks for your help.

</comment></comment></comment><comment><USER42> > In the immortal words of Sherman T. Potter: "Horse hucky!"

?

<comment><USER18> Sherman T. Potter

> > [http://mash.wikia.com/wiki/Sherman_T._Potter](http://mash.wikia.com/wiki/Sherman_T._Potter)

horse huckey:

> > [http://www.urbandictionary.com/define.php?term=horse%20hocke...](http://www.urbandictionary.com/define.php?term=horse%20hockey)

Colonel Potter curses ("Horse hucky!" is at the beginning):

> > [https://www.youtube.com/watch?v=vhagzSEXzic](https://www.youtube.com/watch?v=vhagzSEXzic)

</comment></comment><comment><USER43> "Any packages that really need that much memory could be built in their own 64-bit process and seamlessly integrated into VS"

Wait... did you just tell me to go fuck myself? ;)

<comment><USER44> I believe he did, Bob.

</comment></comment><comment><USER45> Hmm. We must all be a bunch of rubes for running 64-bit code in so many places these days.

<comment><USER45> The mob has spoken! 64-bit is actually good.

</comment></comment><comment><USER46> Run devenv /safemode to load the IDE without third party extensions (think ReSharper) and the thing flies. It's not Microsoft's code that's the problem.

<comment><USER8> We...may have different definitions of "flies". Yes if you disable third party plugins then it should be fast at various points in its lifecycle. At the same time it's not really that fast when you have zero plugins installed...</comment></comment>


Node.JS Help Sheet - <AUTHOR> http://www.gosquared.com/liquidicity/archives/1930 <comment><USER2> This is a very valuable resource.</comment>