Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #116847 > unrolled thread

64 to 32 bit

Back to article view | Back to comp.sys.mac.system

Contents

  64 to 32 bit Gerry <address@domain.com> - 2018-05-31 15:12 -0700
    Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-05-31 18:37 -0400
      Re: 64 to 32 bit gtr <xxx@yyy.zzz> - 2018-05-31 21:27 -0700
      Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-01 01:50 -0400
        Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-01 02:04 -0400
        Re: 64 to 32 bit Your Name <YourName@YourISP.com> - 2018-06-01 18:20 +1200
    Re: 64 to 32 bit Your Name <YourName@YourISP.com> - 2018-06-01 13:52 +1200
      Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-05-31 22:41 -0400
        Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-01 14:50 +0000
          Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-02 01:22 +0000
        Re: 64 to 32 bit "Snit's dysautonomia http://bit.ly/2Jqpplk" <frelwizzen@gmail.com> - 2018-06-02 23:28 -0700
      Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-01 01:29 -0400
        Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-01 01:41 -0400
          Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-01 02:04 -0400
      Re: 64 to 32 bit Tim Streater <timstreater@greenbee.net> - 2018-06-01 08:36 +0100
        Re: 64 to 32 bit Barry Margolin <barmar@alum.mit.edu> - 2018-06-01 11:10 -0400
          Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-01 11:21 -0400
          Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-01 12:49 -0400
            Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-01 12:51 -0400
        Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-01 15:50 +0000
          Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-01 12:54 -0400
            Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-01 13:08 -0400
            Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-02 01:31 +0000
            Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 15:31 +0000
              Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 14:40 -0400
                Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 14:42 -0400
                Re: 64 to 32 bit Barry Margolin <barmar@alum.mit.edu> - 2018-06-02 22:36 -0400
                Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-05 09:24 +0000
            Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 15:39 +0000
              Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 14:44 -0400
                Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 14:49 -0400
                  Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 15:00 -0400
                    Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 15:12 -0400
                    Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 21:44 +0000
                      Re: 64 to 32 bit "John Varela" <newlamps@verizon.net> - 2018-06-04 18:41 +0000
                        Re: 64 to 32 bit Steve Carroll <frelwizzen@gmail.com> - 2018-06-04 12:14 -0700
                        Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-04 19:21 +0000
                          Re: 64 to 32 bit gtr <xxx@yyy.zzz> - 2018-06-04 14:39 -0700
                Re: 64 to 32 bit Tim Streater <timstreater@greenbee.net> - 2018-06-02 19:56 +0100
                  Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 15:04 -0400
                    Re: 64 to 32 bit Alan Browne <bitbucket@blackhole.com> - 2018-06-04 18:54 -0400
                Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 21:43 +0000
                Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-05 09:29 +0000
          Re: 64 to 32 bit Barry Margolin <barmar@alum.mit.edu> - 2018-06-01 15:09 -0400
            Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 15:46 +0000
              Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 12:00 -0400
                Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 16:58 +0000
                  Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 14:50 -0400
                    Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 14:54 -0400
                      Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 15:01 -0400
                        Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 15:12 -0400
                          Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 17:56 -0400
                            Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 18:08 -0400
                              Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-03 03:55 +0000
                                Re: 64 to 32 bit "Snit's dysautonomia http://bit.ly/2Jqpplk" <frelwizzen@gmail.com> - 2018-06-03 07:48 -0700
                                Re: 64 to 32 bit "Snit's dysautonomia http://bit.ly/2Jqpplk" <frelwizzen@gmail.com> - 2018-06-03 11:28 -0700
                            Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-03 03:54 +0000
                            Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-05 09:43 +0000
                        Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 21:37 +0000
                        Re: 64 to 32 bit Your Name <YourName@YourISP.com> - 2018-06-03 12:07 +1200
                        Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-05 09:42 +0000
              Re: 64 to 32 bit JF Mezei <jfmezei.spamnot@vaxination.ca> - 2018-06-02 14:47 -0400
                Re: 64 to 32 bit nospam <nospam@nospam.invalid> - 2018-06-02 14:49 -0400
                Re: 64 to 32 bit Jolly Roger <jollyroger@pobox.com> - 2018-06-02 21:40 +0000
                Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-05 09:45 +0000
              Re: 64 to 32 bit Barry Margolin <barmar@alum.mit.edu> - 2018-06-02 22:35 -0400
                Re: 64 to 32 bit Your Name <YourName@YourISP.com> - 2018-06-03 15:09 +1200
                Re: 64 to 32 bit Lewis <g.kreme@gmail.com.dontsendmecopies> - 2018-06-05 09:47 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#117015

On 2018-06-02 15:04, JF Mezei wrote:

> Ironic that the Apple Apologists are the ones to insist that 32bit apps
> will slow down and accuse those who say they won't slow down of FUD.


[1] To support 32 bit apps, the supporting frameworks and compatible 
lower level support ware needs to be loaded.

That takes up more memory which could cause more swaps to occur.

[2] Since most compiled 32 bit code is less cycle efficient than 64 bit 
code, the time that a core spends on a 32 bit task removes cycles 
available in real time from other tasks.  To be sure, on a system 
running well below 100% CPU load, this will not be at all perceivable by 
the user.

[3] Code compiled to 64 bits results in fewer instructions overall than 
32 bit code.  Less op codes generated.  So, again, less memory impact, 
less time to load the code, etc.  (eg: Pascal code I gen has 10-15% 
fewer instructions generated when in 64 bit).

[4] 64 bit code is also more memory bandwidth efficient as (good) 
compilers will assign as many stack-local variables to registers as 
possible.  (ie: vars in a subroutine).  So there is less 
fetching/storing from/to memory.  That means that other cores are not 
waiting as much for their own memory fetches/stores (which includes code 
fetch) as there is less competition for the memory address/data-buses. 
(This is a much larger impact than you might imagine).

So, for a period of transition Apple let both co-exist, but in the 
interest of evolving the ecosystem they have called an end to it.

This goes beyond run-time.  It also means far less coding, testing and 
debugging for Apple, and for that matter, app developers.

-- 

[toc] | [prev] | [next] | [standalone]

#116939

On 2018-06-02, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2018-06-02 11:39, Jolly Roger wrote:
>
>>> WTF does this mean? Does Apple insert a NOOP between successive
>>> machine instructions so the app only runs half as fast?
>> 
>> Apple isn't "inserting NOOPs".
>> Apple isn't trying to make apps "run half as fast".
>> Apple isn't doing *anything* nefarious.
>> 
>> PURE FUD.
>
> Context: Apple apologists state that 32 bits will slow down.

The only person here making that claim is you. And everyone who
disagrees with you isn't an "Apple apologist", just like any news you
dislike isn't "fake news". Get a clue.

> Other posters ask apple apologists how Apple will slow down 32 bit apps,
> inserts NOOPS ?

Pure FUD.

> In fact, the FUD is from the Apple Apologists who claims 32bit apps will
> slow down.

The fact that the only person here making that claim is you is quite
appropriate then, since you are a well established FUDster.

[remainder of your ever-ignorant ramblings rightfully ignored]

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#117046

In message <nABQC.218093$go7.64935@fx08.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> In fact, the FUD is from the Apple Apologists who claims 32bit apps will
> slow down.

Nope. These are FACTS. I know you're unfamiliar with the concept, but
tough shit, facts are facts.

> They won't slow down any more than they currently run.

Untrue. A 32-bit App in 10.14 will be slower to launch and will take
more resources than the identical app on the identical hardware on 10.13
and will not run at all on 10.15.

-- 
The truth isn't easily pinned to a page. In the bathtub of history the
truth is harder to hold than soap, and much more difficult to find...

[toc] | [prev] | [next] | [standalone]

#116882

In article <fnd8adFjr8qU2@mid.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> On 2018-06-01, Tim Streater <timstreater@greenbee.net> wrote:
> > In article <peq8si$pba$1@gioia.aioe.org>, Your Name
> ><YourName@YourISP.com> wrote:
> >
> >>As of the current information, Apple is saying 32-bit apps will not
> >>run *as* *efficiently* under the next version of macOS (10.14)
> >
> > WTF does this mean? Does Apple insert a NOOP between successive
> > machine instructions so the app only runs half as fast?
> 
> My god, people... Please stop with the FUD. Nothing nefarious is going
> on. This is simple engineering, and nothing more. iOS separates 32- and
> 64-bit frameworks on 64-bit devices such that when all apps running on
> the device are 64-bit, the operating system doesn't bother to load
> 32-bit versions of those libraries. The result is that the system uses
> less memory and launches apps more quickly. Even apps that happen to be
> 64-bit "by accident" but don't actually have 64-bit performance
> optimizations benefit from this memory efficiency. When 32-bit apps are
> thrown into the mix, performance of the entire system is adversely
> affected. There are, of course, other aspects of system and app design
> that can also factor into performance; but that's the key take away from
> Apple's warning.

This type of "don't bother to load things that aren't needed" design is 
much more important on small devices. It doesn't seem like the kind of 
optimization that would be too important on bigger PCs, so I suspect 
it's something different.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#116911

On 2018-06-01, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <fnd8adFjr8qU2@mid.individual.net>,
>  Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2018-06-01, Tim Streater <timstreater@greenbee.net> wrote:
>> > In article <peq8si$pba$1@gioia.aioe.org>, Your Name
>> ><YourName@YourISP.com> wrote:
>> >
>> >>As of the current information, Apple is saying 32-bit apps will not
>> >>run *as* *efficiently* under the next version of macOS (10.14)
>> >
>> > WTF does this mean? Does Apple insert a NOOP between successive
>> > machine instructions so the app only runs half as fast?
>> 
>> My god, people... Please stop with the FUD. Nothing nefarious is going
>> on. This is simple engineering, and nothing more. iOS separates 32- and
>> 64-bit frameworks on 64-bit devices such that when all apps running on
>> the device are 64-bit, the operating system doesn't bother to load
>> 32-bit versions of those libraries. The result is that the system uses
>> less memory and launches apps more quickly. Even apps that happen to be
>> 64-bit "by accident" but don't actually have 64-bit performance
>> optimizations benefit from this memory efficiency. When 32-bit apps are
>> thrown into the mix, performance of the entire system is adversely
>> affected. There are, of course, other aspects of system and app design
>> that can also factor into performance; but that's the key take away from
>> Apple's warning.
>
> This type of "don't bother to load things that aren't needed" design is 
> much more important on small devices. It doesn't seem like the kind of 
> optimization that would be too important on bigger PCs, so I suspect 
> it's something different.

It's important on any device. Do you also suspect Apple is lying about it?

"In OS X v10.6 and later, most built-in apps are 64-bit. The first time
you run a 32-bit application, all of the 32-bit framework slices must be
loaded into memory. This means that loading older, 32-bit-only
applications causes significant memory pressure, particularly on
computers with limited RAM. This often outweighs the additional memory
impact caused by larger data structures."

<https://developer.apple.com/library/content/documentation/Darwin/Conceptual/64bitPorting/indications/indications.html>

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#116914

In article <fnfsfjF5023U5@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> >> My god, people... Please stop with the FUD. Nothing nefarious is going
> >> on. This is simple engineering, and nothing more. iOS separates 32- and
> >> 64-bit frameworks on 64-bit devices such that when all apps running on
> >> the device are 64-bit, the operating system doesn't bother to load
> >> 32-bit versions of those libraries. The result is that the system uses
> >> less memory and launches apps more quickly. Even apps that happen to be
> >> 64-bit "by accident" but don't actually have 64-bit performance
> >> optimizations benefit from this memory efficiency. When 32-bit apps are
> >> thrown into the mix, performance of the entire system is adversely
> >> affected. There are, of course, other aspects of system and app design
> >> that can also factor into performance; but that's the key take away from
> >> Apple's warning.
> >
> > This type of "don't bother to load things that aren't needed" design is 
> > much more important on small devices. It doesn't seem like the kind of 
> > optimization that would be too important on bigger PCs, so I suspect 
> > it's something different.
> 
> It's important on any device. Do you also suspect Apple is lying about it?

the point is that it's a bigger hit on an iphone with 1 gig of memory
versus a mac with 8 or more gig of memory.

[toc] | [prev] | [next] | [standalone]

#116917

On 2018-06-02, nospam <nospam@nospam.invalid> wrote:
> In article <fnfsfjF5023U5@mid.individual.net>, Jolly Roger
><jollyroger@pobox.com> wrote:
>
>> >> My god, people... Please stop with the FUD. Nothing nefarious is going
>> >> on. This is simple engineering, and nothing more. iOS separates 32- and
>> >> 64-bit frameworks on 64-bit devices such that when all apps running on
>> >> the device are 64-bit, the operating system doesn't bother to load
>> >> 32-bit versions of those libraries. The result is that the system uses
>> >> less memory and launches apps more quickly. Even apps that happen to be
>> >> 64-bit "by accident" but don't actually have 64-bit performance
>> >> optimizations benefit from this memory efficiency. When 32-bit apps are
>> >> thrown into the mix, performance of the entire system is adversely
>> >> affected. There are, of course, other aspects of system and app design
>> >> that can also factor into performance; but that's the key take away from
>> >> Apple's warning.
>> >
>> > This type of "don't bother to load things that aren't needed" design is 
>> > much more important on small devices. It doesn't seem like the kind of 
>> > optimization that would be too important on bigger PCs, so I suspect 
>> > it's something different.
>> 
>> It's important on any device. Do you also suspect Apple is lying about it?
>
> the point is that it's a bigger hit on an iphone with 1 gig of memory
> versus a mac with 8 or more gig of memory.

Yes, I understand that. There is still absolutely no indication Apple is
doing anything nefarious here as people are suggesting.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#116928

On 2018-06-02 12:58, Jolly Roger wrote:

> Yes, I understand that. There is still absolutely no indication Apple is
> doing anything nefarious here as people are suggesting.

You are the one arguing 32bit apps will slow down with the next version.
The people you accuse of FUD are the ones who do not believe those apple
will slow doen, do not believe Apple will do anything to slow them down
compared to how they run now.

[toc] | [prev] | [next] | [standalone]

#116929

In article <NFBQC.303971$br4.99392@fx34.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

> On 2018-06-02 12:58, Jolly Roger wrote:
> > Yes, I understand that. There is still absolutely no indication Apple is
> > doing anything nefarious here as people are suggesting.
> 
> You are the one arguing 32bit apps will slow down with the next version.

no, the claim is that 32 bit apps slow down the entire computer, for
reasons that have been explained a few times already.

[toc] | [prev] | [next] | [standalone]

#116932

On 2018-06-02 14:54, nospam wrote:

> no, the claim is that 32 bit apps slow down the entire computer, for
> reasons that have been explained a few times already.
> 

So you're changing your claim. The original claim was that with the
upcoming version of OS-X, 32bit apps will run slower.

[toc] | [prev] | [next] | [standalone]

#116935

In article <tQBQC.259043$nq5.95819@fx36.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

> 
> > no, the claim is that 32 bit apps slow down the entire computer, for
> > reasons that have been explained a few times already.
> > 
> 
> So you're changing your claim. The original claim was that with the
> upcoming version of OS-X, 32bit apps will run slower.

no to both.

the original claim was that 32 bit apps slow down the system.


In article <fnd8adFjr8qU2@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:
> ...iOS separates 32- and
> 64-bit frameworks on 64-bit devices such that when all apps running on
> the device are 64-bit, the operating system doesn't bother to load
> 32-bit versions of those libraries. The result is that the system uses
> less memory and launches apps more quickly. Even apps that happen to be
> 64-bit "by accident" but don't actually have 64-bit performance
> optimizations benefit from this memory efficiency. When 32-bit apps are
> thrown into the mix, performance of the entire system is adversely
> affected. There are, of course, other aspects of system and app design
> that can also factor into performance; but that's the key take away from
> Apple's warning.


In article <fnfsfjF5023U5@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:
> "In OS X v10.6 and later, most built-in apps are 64-bit. The first time
> you run a 32-bit application, all of the 32-bit framework slices must be
> loaded into memory. This means that loading older, 32-bit-only
> applications causes significant memory pressure, particularly on
> computers with limited RAM. This often outweighs the additional memory
> impact caused by larger data structures."
> 
> <https://developer.apple.com/library/content/documentation/Darwin/Conceptual/64bitPorting/indications/indications.html>

[toc] | [prev] | [next] | [standalone]

#116941

On 2018-06-02 15:12, nospam wrote:

> the original claim was that 32 bit apps slow down the system.

Changing the goalposts makes the debate moot. The alerts people get do
not mention making the whole system slower.

[toc] | [prev] | [next] | [standalone]

#116942

In article <yoEQC.345083$RM2.184443@fx05.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

> 
> > the original claim was that 32 bit apps slow down the system.
> 
> Changing the goalposts makes the debate moot. 

nothing changed.

> The alerts people get do
> not mention making the whole system slower.

guess again:
<https://cdn.macrumors.com/article-new/2016/10/peggle-800x450.jpg>

[toc] | [prev] | [next] | [standalone]

#116953

On 2018-06-02, nospam <nospam@nospam.invalid> wrote:
> In article <yoEQC.345083$RM2.184443@fx05.iad>, JF Mezei
><jfmezei.spamnot@vaxination.ca> wrote:
>
>> 
>> > the original claim was that 32 bit apps slow down the system.
>> 
>> Changing the goalposts makes the debate moot. 
>
> nothing changed.
>
>> The alerts people get do
>> not mention making the whole system slower.
>
> guess again:
><https://cdn.macrumors.com/article-new/2016/10/peggle-800x450.jpg>

It'd be funny if he wasn't so fucking pathetic. 

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#116965

On Saturday, June 2, 2018 at 8:55:10 PM UTC-7, Jolly Roger wrote:
> On 2018-06-02, nospam <nospam@nospam.invalid> wrote:
> > In article <yoEQC.345083$RM2.184443@fx05.iad>, JF Mezei
> ><jfmezei.spamnot@vaxination.ca> wrote:
> >
> >> 
> >> > the original claim was that 32 bit apps slow down the system.
> >> 
> >> Changing the goalposts makes the debate moot. 
> >
> > nothing changed.
> >
> >> The alerts people get do
> >> not mention making the whole system slower.
> >
> > guess again:
> ><https://cdn.macrumors.com/article-new/2016/10/peggle-800x450.jpg>
> 
> It'd be funny if he wasn't so fucking pathetic. 
> 
> -- 
> E-mail sent to this address may be devoured by my ravenous SPAM filter.
> I often ignore posts from Google. Use a real news client instead.
> 
> JR



It was Snit who was openly asking how better to camouflage his trolling. 

I have a program I use as well, but it's a bit different. You will not go into a gathering, piss in all the alcohol, pound all the furniture, nab the nicknacks and technicolor yawn in the bathroom without being noticed. Can you cease asking for my attention? 

--
Puppy Videos
http://www.5z8.info/facebook-of-sex_w4l4wg_bomb
https://www.facebook.com/profile.php?id=100012978552519
Jonas Eklundh Communication

[toc] | [prev] | [next] | [standalone]

#116970

On Saturday, June 2, 2018 at 8:55:10 PM UTC-7, Jolly Roger wrote:
> On 2018-06-02, nospam <nospam@nospam.invalid> wrote:
> > In article <yoEQC.345083$RM2.184443@fx05.iad>, JF Mezei
> ><jfmezei.spamnot@vaxination.ca> wrote:
> >
> >> 
> >> > the original claim was that 32 bit apps slow down the system.
> >> 
> >> Changing the goalposts makes the debate moot. 
> >
> > nothing changed.
> >
> >> The alerts people get do
> >> not mention making the whole system slower.
> >
> > guess again:
> ><https://cdn.macrumors.com/article-new/2016/10/peggle-800x450.jpg>
> 
> It'd be funny if he wasn't so fucking pathetic. 
> 
> -- 
> E-mail sent to this address may be devoured by my ravenous SPAM filter.
> I often ignore posts from Google. Use a real news client instead.
> 
> JR



LOL! How did F. Russell get *so* self-centered he believes everything is about himself?? Who *doesn't* know that this kind of malarkey is F. Russell's modus operandi, not the approach of Steve Petruzzellis? It's all just projection... the endless posting, the posting with Steve Petruzzellis's name, the writing of gibberish, the outbursts... the panties in a twist and eagerness to show how flustered he is over being banned from the sandbox for pissing in it again. Now why the added need to debug JavaScript via ODBC connectivity in a server system? Predictably, he didn't state this as part of his inevitably self-serving 'standard'. 

Enjoy the silence in the teeming sewer of my KF. Despite F. Russell's claim that he has "no skill in making automated posts" (a lie as evidenced by the fact that he posts over 1000 times a month) he was quoted asking others how they would install a virus remotely. F. Russell is far too unintelligent to write a useful script. The only scripting he's ever shown he can do is click, click, drool, drool. 

--
This broke the Internet
http://www.5z8.info/stalin-will-rise-again_j3h5uj_nakedgrandmas.jpg
Jonas Eklundh

[toc] | [prev] | [next] | [standalone]

#116952

On 2018-06-02, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2018-06-02 15:12, nospam wrote:
>
>> the original claim was that 32 bit apps slow down the system.
>
> Changing the goalposts makes the debate moot.

The only one trying to move goal posts here is you.

> The alerts people get do not mention making the whole system slower.

Another ignorant lie easily proven wrong. You just can't stop blabbing,
can you? What a fucking fool.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#117048

In message <yoEQC.345083$RM2.184443@fx05.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2018-06-02 15:12, nospam wrote:

>> the original claim was that 32 bit apps slow down the system.

> Changing the goalposts makes the debate moot. The alerts people get do
> not mention making the whole system slower.

Nor do they mention the app being slower, you FUD spreading shit.


-- 
TO CHANGE THE FATE OF ONE INDIVIDUAL IS TO CHANGE THE WORLD. I REMEMBER
THAT. SO SHOULD YOU. Death still hadn't turned to face her. 'I don't
see why we shouldn't change things if it makes the world better,' said
Susan. HAH. 'Are you too scared to change the world?' Death turned.
The very sight of his expression made Susan back away. He advanced
slowly towards her. His voice, when it came, was a hiss. YOU SAY THAT
TO ME? YOU STAND THERE IN YOUR PRETTY DRESS AND SAY THAT TO ME? YOU? YOU
PRATTLE ON ABOUT CHANGING THE WORLD? COULD YOU FIND THE COURAGE TO
ACCEPT IT? TO KNOW WHAT MUST BE DONE AND DO IT, WHATEVER THE COST? IS
THERE ONE HUMAN BEING ANYWHERE WHO KNOWS WHAT DUTY MEANS? --Soul Music

[toc] | [prev] | [next] | [standalone]

#116937

On 2018-06-02, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2018-06-02 14:54, nospam wrote:
>
>> no, the claim is that 32 bit apps slow down the entire computer, for
>> reasons that have been explained a few times already.
>
> So you're changing your claim. The original claim was that with the
> upcoming version of OS-X, 32bit apps will run slower.

Liar. I'm not sure what you expect to gain from telling lies when anyone
can easily verify you are lying:

In article <fnd8adFjr8qU2@mid.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> My god, people... Please stop with the FUD. Nothing nefarious is going
> on. This is simple engineering, and nothing more. iOS separates 32-
> and 64-bit frameworks on 64-bit devices such that when all apps
> running on the device are 64-bit, the operating system doesn't bother
> to load 32-bit versions of those libraries. The result is that the
> system uses less memory and launches apps more quickly. Even apps that
> happen to be 64-bit "by accident" but don't actually have 64-bit
> performance optimizations benefit from this memory efficiency. When
> 32-bit apps are thrown into the mix, performance of the *entire*
> *system* is adversely affected. There are, of course, other aspects of
> system and app design that can also factor into performance; but
> that's the key take away from Apple's warning.

Repeat: *entire* *system*

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#116946

On 2018-06-02 19:01:45 +0000, JF Mezei said:
> On 2018-06-02 14:54, nospam wrote:
>> 
>> no, the claim is that 32 bit apps slow down the entire computer, for
>> reasons that have been explained a few times already.
> 
> So you're changing your claim. The original claim was that with the
> upcoming version of OS-X, 32bit apps will run slower.

Talk about making mountains out of molehills.  :-\

Nobody said "32bit apps will run slower".

Apple has said 32-bit apps won't run "as efficiently" in the next 
version of macOS and the warning messages in 10.13.4 say the app isn't 
"optimized". Nobody knows exactly what, how, or why that means ... at 
least nobody you can say anything without breaking their NDA.

We *might* find out more at the WWDC, or we may have to wait for actual 
real-world usage after the new version has been publicly released. It 
may also depend on each individual app itself - some may work more 
"efficiently" than others.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web