Major Project Idea: Chrome for x64?

[Erik Bean]

Chrome is much like an OS system, so why cant we take it one step further and make it process a little bit faster. I'm sure much of us who run the dev and canary channels of the Chromium project and take the time to submit any bugs we see, run a x64 computer and OS system as is. Many users do and it would also make Chromium products more usable to company's and those who's build and websites on x64.

Only difference (I'm sure we already know) between x64 and x86 is processing speed. Well there is more, but its worth an attempt ain't it? All input welcome, including from those who work on Google products including the Chromium project especially.

[Pavel Ivanov]

> Only difference (I'm sure we already know) between x64 and x86 is processing
> speed.

One more difference - amount of consumed memory. For x64 it's bigger.
But I'm not against trying it out.


Pavel

> --
> Chromium Discussion mailing list: chromium...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-discuss

[dhw]

There are already 64-bit builds of Chromium for Linux.

You can add a STAR to the following other issues to be notified of
updates:

64-bit Chrome for Windows: http://code.google.com/p/chromium/issues/detail?id=8606

64-bit Chrome for Mac: http://code.google.com/p/chromium/issues/detail?id=18323

[Erik Bean]

Staring it don't do me no good if they move at a snails pace and have figure out that bubblegum patches a hole when there sitting on a tub of sealant. :/ most of what x32 is now can be retrofitted and built UP and built into a working if not fully functional x64 bit within the next 3 stable updates or less. Just gotta go. In 2009 the issue was brought up, and has little fire since. Now the world is quickly pacing to x64, and chrome isn't far behind.

[krtulmay]

And posting here and just welcoming "input" will do more good?

On May 25, 6:58 pm, Erik Bean <eebe...@yahoo.com> wrote:
> Staring it don't do me no good if they move at a snails pace and have
> figure out that bubblegum patches a hole when there sitting on a tub
> of sealant. :/ most of what x32 is now can be retrofitted and built UP and
> built into a working if not fully functional x64 bit within the next 3
> stable updates or less. Just gotta go. In 2009 the issue was brought up,
> and has little fire since. Now the world is quickly pacing to x64, and
> chrome isn't far behind.
>
>
>
>
>
>
>
> On Friday, May 25, 2012 7:42:21 PM UTC-4, dhw wrote:
>
> > There are already 64-bit builds of Chromium for Linux.
>
> > You can add a STAR to the following other issues to be notified of
> > updates:
>
> > 64-bit Chrome for Windows:
> >http://code.google.com/p/chromium/issues/detail?id=8606
>
> > 64-bit Chrome for Mac:
> >http://code.google.com/p/chromium/issues/detail?id=18323
>

> > On May 25, 11:26 am, Pavel Ivanov <paiva...@gmail.com> wrote:
> > > > Only difference (I'm sure we already know) between x64 and x86 is
> > processing
> > > > speed.
>
> > > One more difference - amount of consumed memory. For x64 it's bigger.
> > > But I'm not against trying it out.
>
> > > Pavel
>

> > > On Fri, May 25, 2012 at 2:09 PM, Erik Bean <eebe...@yahoo.com> wrote:
> > > > Chrome is much like an OS system, so why cant we take it one step
> > further
> > > > and make it process a little bit faster. I'm sure much of us who run
> > the dev
> > > > and canary channels of the Chromium project and take the time to
> > submit any
> > > > bugs we see, run a x64 computer and OS system as is. Many users do and
> > it
> > > > would also make Chromium products more usable to company's and those
> > who's
> > > > build and websites on x64.
>
> > > > Only difference (I'm sure we already know) between x64 and x86 is
> > processing
> > > > speed. Well there is more, but its worth an attempt ain't it?
> > > > All input welcome, including from those who work on Google products
> > > > including the Chromium project especially.
>
> > > > --

> > > > Chromium Discussion mailing list: chromium-disc...@chromium.org

[Torne (Richard Coles)]

On 25 May 2012 19:09, Erik Bean <eeb...@yahoo.com> wrote:
> Only difference (I'm sure we already know) between x64 and x86 is processing
> speed.

This is not true. Whether x86-86 is faster or slower depends on what
you're doing, and in general it often adds up to nothing: the code can
be slightly more efficient because of the extra registers, but the
instructions and pointers are larger so there is more cache pressure,
making it need to access main memory more often.

The advantages of x86-64 for programs in general is that 64-bit tasks
can address more memory than 32-bit ones; Chromium has much less need
for this than most programs because of the multiprocess architecture:
each renderer process has its own 32-bit memory space it can use
without filling up the space used by other renderers.

There is a 64-bit version for Linux, but as far as I know the reason
for that is because running 32-bit tasks on 64-bit Linux is more
complicated and requires more memory; you need 32-bit versions of all
the system libraries you are using which must be installed from
somewhere and take up RAM. On Windows 32/64 bit compatibility is
handled differently and this is much less of a problem.

--
Torne (Richard Coles)
to...@google.com

[Erik Bean]

I know that the Chromium project has been looking at x64 for a while, like since 2009 while. This would allow the project in hopes to access and return faster giving the user a better use of the web. Witch has been what the project has always been about.

[Imagine]

i use 64 bit versions of (,firefox nightly, explorer and opera) and they are much faster than 32 bit browser on my computer :)

[Tibor]

> Only difference (I'm sure we already know) between x64 and x86 is processing speed. Well there is more, but its  

I doubt end users would feel any speed difference between x86 and x64 on Windows in a desktop application.

The main benefit would be the access to more RAM, but this wouldn't benefit the _average_* end user either.

* People posting to these lists are not average users.

[Erik Bean]

Chrome im sure will be noticeable faster. Most browsers run like a program, Chrome runs like an OS system. Any little upgrade could make it run or act faster or better in some way.

[Tibor]

Are you not confusing Chrome Browser and Chrome OS?

Chrome Browser on Windows is regular a Win32 executable.

If there would be a speed difference it would be of milliseconds, which is unnoticable.

In slow applications like browsers where the bottleneck is the download speed and rendering even even differences close to a second may not be noticed.

However, I can be convinced by a properly conducted comparative performance test.

[Evans Turner (Work)]

I wouldn't say that "milliseconds are unnoticeable." Milliseconds add-
up! Would 2,000 milliseconds be noticeable? (Answer: YES)

Even a couple milliseconds can be a very big deal when compounded /
multiplied programmatically. I plan to write emulators in Javascript
and I know performance is going to be a *huge* challenge. If it's true
that 32-bit code runs slightly slower on a 64-bit OS than it would on
a 32-bit OS, then I definitely want a native 64-bit build.

Even if a performance difference is imperceptible in most usage
scenarios, it certainly would not be true for *all* usage scenarios. I
don't know enough to say if 64 bit would shave off milliseconds or
not. If a native 64-bit build would improve performance even a little
bit, then I want it.

-Evans

[PAEz]

I dont use 64bit, but considering Chrome is pushing the idea of web
apps I think statements like....

"In slow applications like browsers where the bottleneck is the
download
speed and rendering even even differences close to a second may not
be
noticed. "

...are extremely short sighted.
Try doing a blur (or worse, a gaussian blur) on an image that is
1280x1024 pixels. Even one millisecond per pixel will add up to alot
of time.....
1280 * 1024 / 1000 / 60 = 21.8453 minutes!
Chrome is so much more than just something to look at web pages with.

On May 29, 6:55 am, "Evans Turner (Work)" <jevansturnerw...@gmail.com>
wrote:

[Tibor]

I don't think this is the forum where you should play with words. 

Sure, 10 million milliseconds would be noticed by anyone, however I don't think anyone except people who think are funny because of this would think of 10 million in such cases.

Anyway, let's make it simpler. When browsing (not editing images or videos like PAEz) you will not notice differences in range of 1-2 seconds. 

Usability tests prove it, this is the reason why many optimisations are not worth doing in desktop applications. 

I.e. loading this thread requires ~4.76 seconds on my Core I7 Win7 x64 laptop and about the same time on my Pentium 4 WinXP x86 desktop on same network.

It requires 38 requests to load and even with Chrome's optimised multiple connection loading mechanism this requires lots of time.

Only loading 953A299DB1DC4BDAE9465B4C9F0350F7.cache.js required 929 ms. 

No CPU processing time was required for it, only network and disk communication.

Would you notice any difference if it were 5.76 seconds or 3.76 seconds? No.

And there's nothing to add up, loading a web page is be X seconds with x68 executable and Y seconds with x64 executable and the difference between x and y is not noticeable for an average user in average use cases.

And like Richard Coles wrote, it may happen that x64 is slower than x86.

Javascript is slow in general, and not because running x86 on x64 CPU but because of its architecture (i.e. it's not compiled). 

You want it fast write a NACL plugin.

You are right, nothing is valid for _all_ user scenarios, but since development resources are very limited one must always optimise to most common user scenarios (there are very few exceptions to this).

x64 would be useful for scenarios requiring more than 4 GB memory but the average user will not use their browser in a way what would require that amount of memory.

x64 still has some drawbacks (i.e. the neeed to support 2 builds, 2 installs) so it's not that trivial to decide to support it officially.

[Tibor]

I don't think image editing is a typical use of a browser. 

Sure it can be done but if it would javascript the performance would be unusable. Could be native code (NACL) but I wouldn't call that the Chrome browser anymore.

Or could be a real web app like  http://pixenate.com/ is, but apps like this run on server so it doesn't make any difference what the client is (can be any browser, or desktop app, or a phone, or anything what is capable of HTTP communication).

Maybe it wasn't clear enough but I've replied in context of using a browser for browsing (average use case of average user).

[PhistucK]

Note that the first sentence of the first post from the original poster was that Chrome is much like an OS, so the browser only for browsing context is not the right context/assumption of this thread.

☆PhistucK

--
Chromium Discussion mailing list: chromium...@chromium.org

[Tibor]

Maybe it wasn't clear enough but the context I've given was the context of _my_ answers. 

I still claim that Chrome Browser in its current form is no different from any other Win32 application on Windows as it is a Win32 executable.

Having extensions (API, plugins, addons, there are many names) doesn't make something an OS or anything close to an OS.

Neither does the more user profiles.

If it would be so many desktop programs would be like an OS.

However, this makes no difference in regards to performance or average users or average use cases.

[Erik Bean]

Ok, i know I've not replied in a while, so I've just spent the last ten minuets catching up on post (I've been in surgery and recovery last few days).

Many applications rather Java or just plain HTML or HTML5 are starting to require x64 bit to run faster. Just the other day, my brother was on a video game on my Chrome browser (Minecraft) and it requires a x64 browser to play most of the games features. Many gaming computers require the same. Pick up a game box for PC and read the back x64 bit BROWSER meaning IE EXPLORER. Chrome is getting left in the dark ages.

Speed wise, sure the average user with a computer that they take care of wont notice a difference of a second or three. As to someone like a normal person who refuses to do normal maintenance and calls to someone like me who has to come out almost bi weekly to do maintenance and speed up there computer just by cleaning out there cookies and temp files, any speed boost counts as a second on out computer will be almost ten on there.

Yes I'm seventeen, and if you think picture editing isn't everyday thing, you better go look at Facebook and a high school and college campus again. All these apps on Facebook and online are used DAILY. Teenagers look to them to make memory's out of there photos. So if chrome can make there browser able to handle this, and make Java 7 x64 integrated into the browser then this will be great.

[PAEz]

Tibor your aiming way to low, Google are aiming for the future.
Chrome will become alot more than just a browser, it will become an
application framework.
Why develop apps for a particular OS when you can target HTML5 and
have it run on everything?
JS is NOT slow. Yes its slower than compiled applications but
probably not as much as you may think. Not to long ago Delphi coders
where surprised and rather annoyed at the fact that you could render a
mandelbrot faster in Chrome than with a compiled app made from
Delphi. Think its not up to making large apps because its not a true
OOP language, then something can always be done about that. Thats
what Jon Lennart Aasenden did, he saw that html and js was a great
target for mobile devices but wanted all the power of pascal he was
use to so with the help or Eric Grange created the awesome Smart
Mobile Studio ( http://op4js.optimalesystemer.no/about/ ).
Thinking something is good enough as it is in the world of technology
is death. Look at mobile phones, once they just made phone calls and
people thought thats all you needed. But now they do sooooo much more
and millions of people buy them.
So asking why Chrome isnt using something that could make their
"browser" better (even if its only a tiny bit better) thats been
around for a while now seems like a very valid question and arguing in
the defence of average being good enough just seems silly.

[Tibor]

Erik, most of those image editing apps are either Flash/Java (not javascript)/Silverlight, either run on server. 

So in either case it makes not much difference what the client is, because in first case the OS runs the code, in second case image processing has nothing to do with your computer, all is done on server so speed is only limited by bandwidth.

This might change with html5 eventually, assuming html5 editing will perform better than server processing and there will be companies/individuals who will want to make their image editors open source.

As about the future? You're most likely banging open doors about Chrome x64, probably it is delayed because it's too much overhead to support both x86 and x64 versions of a software, not to mention that x64 couldn't use x86 plugins so they have to wait until all third party dependencies have stable x64 release. Probably this latter is the reason that IE defaults to x86 on x64 Windows, IE x64 is only an option.

[Tibor]

I'm a developer myself so I know exactly what the capabilities of javascript and some other languages are.

I'm not aiming anywhere, I just find it ridiculous all this "major" thing about something what actually doesn't make much difference.

There are other areas where performance could be really improved (i.e. there was and mayber there still is huge investment into improving javascript and this really pays back), and probably Chrome developers are using their resources in those areas instead of wasting time with something what might not gain any benefit.

Will there be official Chrome x64? Most probably will. 

When? Who knows, it depends on so many factory that maybe even Chrome team can't answer this question.

Am I against it? Of course not, I don't care at all because I know it wouldn't make any difference.

If you or others are so confident that Chrome x64 would be so much faster why don't you prepare some benchmarks to prove it?

Here's a real life example for non-developers about how easy is to choose the wrong optimisation. One might think that a small part of a process has very bad performance, they invest into improving it only to find out that it made no difference to the process becasue other parts are performing much worse.

http://www.nature.com/news/2004/040920/full/news040920-2.html 

The question was is it easier to swim in water than in syrup? And most of us would answer yes because syrup is sticky and thick so it must be very hard to swim in it.

But it turned out that thickness and stickyness (viscosity) aren't the real enemy when humans swim (depends on shape), instead the most effort is needed agains turbulence what is about the same in either cases.

So it would have been a waste to invest in swimming suites with lower viscosity, because even with 100% improvement there wouldn't have been a significant change to overall swimming performance.

Same about software, it is very easy to pinpoint issues and resolve them only to find out that it made no difference to the overall process. Yes, one method in code is now 100% faster or uses less memory, but the overall impact is below 0.1% so N days of development were wasted (N is usually more than 5).

[Erik Bean]

The motto of just one thing to make a difference if not just in the slightest will make the best. 

Btw, go to www.html5test.com chrome dev is leading with html5 (if you have the latest dev). Just an inch makes the difference between a mile and some big number. Chromium project is a PROJECT about getting the best to the end user. No I'm not just some punk who don't know anything. 

This blog is about where the patches and rebuilds are needed. x64 gives us a chance to not only be the first to make a new standard, but create a better model. If nothing else, atleast fail tryin.

[Chris Silvetti]

I've gotta agree. Unless you have some positive input, save your opinions or go cry somewhere else...

and since you've noticed and have seemingly had a problem with it since as far back as '09, what 

are _your_ contributions or efforts in resolving this "problem" ?

SMDH 

Women...

[Erik Bean]

Re reading the past post, and researching x64 vs x86 vs AnyCPU. This is would be a jump for Google Chrome and any other Google product to take the plunge into the x64 area of the processing world.

Chromium:

I suggest specificity for Chrome, we redefine how it manages space, create a "Smart Browser". I mean everything else is getting brains, why not our browser. If not familiar with x64, it allows 16 EB (Windows) vs only 4B and also allows more control over how memory is controlled (if you have Norton like i do, it would be welcomed as i'm tired of seeing the little pop up saying its using all my memory).

     With this smart browser we can redefine how memory is controlled. Memory needs another file to run faster, create it and start processing it. If it becomes to much, use the new notification center to send a notification              to the user to ask the user to clean the browser. No more slow internet, and another leap for Chrome.

     Another way to use this is to use this is to re process how pages are handled, it might lead to less crashes, or even a sandbox mode in dev and canary in x64? This would allow to isolate web pages and plugins that are causing problems and debug them without having to download third-party software.

A "Smart Browser" would be the next step and would be a leader among others, and could even be implemented into x86 and other Google products such as the OS to allow it to run even faster and control better.

For those who don't understand what i'm saying, think of it like this:  You have a car, and you are upgradeing its insides to make it handle like nothing ever created before. You could make Lamborghini ( and Mercedes jealous with this upgrade.

[Jakob Kummerow]

Sounds like you have some serious misunderstandings about x64. Here are a few facts (some of these have been mentioned before in this thread):

• 64bit apps are not faster than 32bit apps. (Well, sometimes they're a bit faster, sometimes they're slower, it depends on several factors, there is no general rule.)
• 64bit apps are certainly not "smarter" than 32bit apps. (What does being "smart" have to do with pointer size?)
• 64bit apps use more memory than 32bit apps. (How much more exactly again depends on the app, typically 1.5x - 2x.)
• 64bit processes can address more memory than 32bit processes, but thanks to Chrome's multi-process model, a 32bit address range limit per process is not a serious limitation at this time.
• Going from 32 to 64 bits does not lead to fewer crashes (why would it?), nor does it enable sandboxing (32bit Chrome is sandboxed too).
• 64bit Chrome exists already for Linux, where you can compare it side-by-side to the 32bit version. Go ahead and give it a spin. Prepare to be disappointed if you expected to see a big difference.

[Tibor]

> No more slow internet, and another leap for Chrome.

Could you please explain to those who don't have as much knowledge as you how x64 would make internet faster?

And FYI, at least Internet Explorer has x64 version so Chrome could be at most the second, not the leader browser what is x64.

[Evans Turner]

Erik Bean seems to have many misconceptions in this request, but I would still like to address what you have said, Tibor.

A *slight* improvement to JavaScript performance would drastically improve things such as emulating a CPU architecture. You might say: "But Javascript isn't well-suited to that!" Well, what a slight performance improvement means that it *is* more-suitable for that usage scenario?

Actually, the capabilities and performance of JavaScript have changed a lot in recent years. Emulators have already been made in JavaScript. Even a slight performance improvement would enable new uses that weren't practical before.

I don't know if it's true or a myth that JavaScript would run slightly faster if the V8 engine was native 64-bit; or that the current 32-bit engine runs slightly faster on a 32-bit OS. Either way, I want the fastest JavaScript performance available.

-Evans

[Evans Turner]

...and my point is that the typical use can change as performance limitations are overcome.

-Evans

[Erik Bean]

Well not everything I mentioned is just a x86-64 idea.

A "Smart Browser" can YES push Chrome past IE. If you don't think it can, then please, do us all a favor, and stop posting in the Google forms. Thanks.

Even if its just .1 or .001 seconds of search time and processing time, when you are going from page to page and have more than one tab open streaming, downloading, and trying to use facebook at the same time like many users do. Them seconds add up per page, so lets see, thats the file its downloading, processing the music from source to user, and ummm. Wait, there streaming something too... so yeah. It's not uncommon to see that anymore.

Then there is space. A "Smart Browser" that can control how it streamlines it memory and cookies to better process and output. That could take off even more time, and we all know you want your results faster, not slower. Plus when you have chrome (6 chrome.exe plus 2 or 3 other google programs), Apple (5 programs), skype, Yahoo (3 programs), antivirus, plus more fighting for memory and cpu usage, and I keep my computer clean daily.

From what i've practiced and seen, this is possible, and sure, maybe it would only give MINOR improvements, but even its only .03 seconds faster and the memory better, at least it happened. A radical idea got us Google Chrome, so why can't a radical idea make it better? What's the worse that happens? It fail? So scrap it and move on.

Evans Turner::

From what i've heard it's faster.

[Pavel Ivanov]

> A radical idea got us Google
> Chrome, so why can't a radical idea make it better? What's the worse that
> happens?

The worst that can happen is you won't be able to use any of your
plugins. Which could include Flash, Adobe PDF Reader, Silverlight,
Netflix movie streaming and whatever else is listed for you on
chrome://plugins/.


Pavel

> --
> Chromium Discussion mailing list: chromium...@chromium.org

[PhistucK]

Plus wasted engineering time that will make other features/bugs get implemented or fixed slower. ;)

☆PhistucK

[Erik Bean]

It's simple minded thinking like that, that is the reason you are simple ground level techs who only test out the products and report to the people who get paid to fix and take this to mind. Good luck with everything. The reason I brought this up, is because Google Chromium x64 on Windows has been a struggle since 09 and needs fresh ideas. Yes some of mine have been things that apply outside the box and not just to x64. I'm sorry if that is beyond your scope of thinking, but its not mine, nor others who are glad to have me as their tech support. My time runs in excess of $100 an hour for just simple things online, yet I do this for fun. 

If I was you, I would just limit the negative mind scope to the simple minded basic user issues about how screens aren't really white or how they can't start Chrome or don't know how to start it from the desktop, instead of something that has been a struggle since 2009. I've been drumming off basic Intel and Windows x64 of what IT WAS MEANT TO BE. Got it? NOT WHAT IT CAN'T BE.

Not lets try this again... Anyone got an idea of how to get x64 for the Chromium Project in Windows? It was the best built of them all and is always getting improved, but is still x86, not AnyCPU. So i'm sure there is something we can do to make it run better.

[Torne (Richard Coles)]

You are being extremely rude. Please either stop insulting people or stop posting. You are also apparently refusing to understand the technical explanations of why your basic assumptions are wrong.

One last time: x86-64 is not faster.

[PhistucK]

Yes, there is. Send patches.

☆PhistucK

[Erik Bean]

Torne:

     I'm not the only one being rude, it was not meant to be more as eye opening. This has been attempted since 09 and is still being attempted. STILL being the key word. It just needs fresh ideas.

PhistucK:

     Yes patches work, but please read what i wrote to Torne about STILL being attempted. Its not a project that was aborted or wasted. Someone that gets PAYED to do this thinks its worth doing. This thread was posted to get fresh ideas not insults and prompts we see every day from average people on the street. Sure a patch is something we do when we see a hole, but how do you take something that works really really well one the lower tier, and take it to the next rung when it's almost there as is?

[Stephen]

FYI I wouldn't waste any time trying to convince this child the reasons. He's 17 YOA, still in high school, and obviously knows little about the technology you're trying to explain to him; https://plus.google.com/116014210214782770958/about

On Tue, Jul 17, 2012 at 11:44 AM, Erik Bean <eeb...@yahoo.com> wrote:

t's simple minded thinking like that, that is the reason you are simple ground level techs who only test out the products and report to the people who get paid to fix and take this to mind. Good luck with everything. The reason I brought this up, is because Google Chromium x64 on Windows has been a struggle since 09 and needs fresh ideas. Yes some of mine have been things that apply outside the box and not just to x64. I'm sorry if that is beyond your scope of thinking, but its not mine, nor others who are glad to have me as their tech support. My time runs in excess of $100 an hour for just simple things online, yet I do this for fun. 

--
Best Regards,
Stephen Allen

http://webweenie.blogspot.ca/

[Joshua Woodward]

With all due respect Stephen, you can't assume, based on that he is only 17, his level of knowledge in this category.

There is  8-10 yr old Google employee, that Is their Ubuntu expert.

Joshua Woodward

http://joshuawoodward.com/ +
http://twitter.com/howtohtml5

[Evans Turner]

Stephen's "assumption" was actually based on the content of Erik's posts...not his age.

-Evans

On Saturday, July 21, 2012 12:04:44 PM UTC-4, Joshua Woodward wrote:

With all due respect Stephen, you can't assume, based on that he is only 17, his level of knowledge in this category.

There is  8-10 yr old Google employee, that Is their Ubuntu expert.

Joshua Woodward

http://joshuawoodward.com/ +
http://twitter.com/howtohtml5

On Jul 21, 2012 5:18 AM, "Stephen" wrote:

FYI I wouldn't waste any time trying to convince this child the reasons. He's 17 YOA, still in high school, and obviously knows little about the technology you're trying to explain to him; https://plus.google.com/116014210214782770958/about

[Stephen]

Exactly, just got tired of his ranting. Wouldn't have been so bad if he actually knew something about it. Sorry to have gone that far, but he didn't take the hint.

[Joshua Woodward]

 "He's 17 YOA, still in high school, and obviously knows little about the technology you're trying to explain to him"

That sentence, to me, focuses on age and not content...that is where my statement came from.

--

Google+ - http://joshuawoodward.com/+

Twitter - @howtohtml5

[Evans Turner]

Looks like multiple supporting facts that led to his conclusion :)

-Evans

[Emanuel Dahlberg]

Is there any news on this? Is it planned?

I get that it probably would not matter that much for the end user, but it would allow embedding Chrome in more applications.

http://code.google.com/p/chromiumembedded/issues/detail?id=394

/ Emanuel

[Michael R Lawrence]

[krtulmay]

As already mentioned in the Chromium Embedded issue you linked to, "if/when Chromium supports a 64bit Windows build we can add CEF support."

64-bit Chromium builds already exist for Linux. As far as I know, yes, 64-bit Windows and Mac builds are planned and being worked on. The links for those bugs were already listed way at the beginning of this thread:

64-bit Chrome for Windows:   http://code.google.com/p/chromium/issues/detail?id=8606 

64-bit Chrome for Mac:   http://code.google.com/p/chromium/issues/detail?id=18323