On Sep 10, 2013, at 23:47 , Tom Davie wrote:
> Note, this was actually more significant on x86, where most of the mess
> caused by CISC (like having bugger all registers) got sorted out.
? VAX had 16, M68K had 16, hmm, NS32032 only had 8. I’d say this was a an
Intel ’86 problem, not a CISC
On Sep 14, 2013, at 16:58 , David Duncan wrote:
> On Sep 14, 2013, at 7:37 AM, vipgs99 wrote:
>> So do I need replace all int to NSInteger?
>
> Technically no, but generally you do need to evaluate every usage of data
> types of a specific width and ensure that in 64-bit mode you won’t exceed
You should never be using int in the first place except for API that are
already using int, like many libc functions return type.
Use the types that fit the API you are using, and if you have to write some
API, use types from stdint.h that fit your need.
Le 14 sept. 2013 à 16:37, vipgs99 a écr
There's a transition guide, I'd start by reading that. Good news, Apple has
done this twice before and so the instructions are good and the tools are good
at pointing out places you may have issues. Bad news, a bit change is hard even
if you have used NSInteger, NSUInteger and CGFloat ubiquitous
On Sep 14, 2013, at 7:37 AM, vipgs99 wrote:
> So do I need replace all int to NSInteger?
Technically no, but generally you do need to evaluate every usage of data types
of a specific width and ensure that in 64-bit mode you won’t exceed the bounds
of what an int can store.
It is more common
So do I need replace all int to NSInteger?
On 13-9-11 3:50, Fábio Bernardo wrote:
I don't get the advantage... What I am missing?
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe
wrote:
Well, since nobody else has commented, let me be the first to say:
YES! YES! YES! THANK Y
On Sep 10, 2013, at 3:19 PM, Fábio Bernardo wrote:
> Most OSX code works on 32 as well as 64bits. I can't say the same for some
> opensource (Linux) frameworks. And will enlarge the binary size, in my
> opinion, without any gains.
Not anymore, really; the advent of features such as ARC, the no
I really don't get why people are freaking out about this. Apple is
continually evolving its OS architecture. That's a good thing.
This isn't about Apple only meeting today's needs. This is about Apple
preparing to meet tomorrow's needs.
I believe we'll start to see a new crop of apps that will
Note: this was just added 2 years ago. So it is relatively a recent change.
Yes, most java developers in the enterprise are still using Java 6 or earlier.
Sent from my iPad
On Sep 11, 2013, at 2:44 AM, Jean-Daniel Dupas wrote:
> This is the contrary. In Obj-c all pointers are effectively doub
On Sep 10, 2013, at 2:19 PM, Fábio Bernardo wrote:
> without any gains
Unless, of course, you discuss apps that actually need it ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
Cocoa-dev maili
Most OSX code works on 32 as well as 64bits. I can't say the same for some
opensource (Linux) frameworks. And will enlarge the binary size, in my opinion,
without any gains.
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 9:11 PM, Sean McBride
wrote:
> On Tue, 10 Sep 2013 20:01:36 +, Abdul S
I don't get the advantage... What I am missing?
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe
wrote:
> Well, since nobody else has commented, let me be the first to say:
> YES! YES! YES! THANK YOU APPLE!!
> --
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-
On 11 Sep, 2013, at 11:01 pm, Vincent Habchi wrote:
> Probably not. I fear many people will think that with 64-bit pointers they
> get a lot of usable space, and then see their code crippled by low memory
> warnings.
>
The conversion guide makes a particular point about memory pressure on s
Scott,
> No, but it's great to device to access data, perhaps even bits pulled out
> from a huge pile, and preferably pulled out extremely quickly.
> And, anyway, why shouldn't it be a huge database machine???
I meant, it is not designed to serve as a database machine. I can’t possibly
imagine
On Wed, Sep 11, 2013 at 12:41 PM, Jean-Daniel Dupas
wrote:
>
> Thanks for this remainder, but I think we all already know that 620k is
> enough for anyone…
Well, I must confess I didn't know that. I thought 640k was required.
___
Cocoa-dev mailing lis
On 11 Sep, 2013, at 5:31 pm, Vincent Habchi wrote:
> But what bother me most, is that I don’t really see the point. A smartphone
> is a phone, it is neither a web server nor a huge database machine nor a
> supercomputer. Who wants to mmap 5 GiB files on a phone? Which process needs
> more tha
> Thanks for this remainder, but I think we all already know that 620k is
> enough for anyone…
Frankly, Jean-Daniel, I don’t want to get involved in a pointless bickering,
but all I need on a phone was almost already running twenty-five years ago on
my first Atari 520ST with, yes, 512 KiB of RA
Le 11 sept. 2013 à 11:31, Vincent Habchi a écrit :
> Mostly, this is not going to change anything. You will see your code size
> increase, because unless you use PIC, you’ll have to store 64-bit addresses
> instead of 32. There will be more cache misses as your memory space becomes
> sparse.
Mostly, this is not going to change anything. You will see your code size
increase, because unless you use PIC, you’ll have to store 64-bit addresses
instead of 32. There will be more cache misses as your memory space becomes
sparse. It will surely run faster, but not because the bus size has be
This is the contrary. In Obj-c all pointers are effectively double size, but in
Java, they are not.
See “Compressed oops" at
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
Le 11 sept. 2013 à 00:18, Paul Franz a écrit :
> Should be interesting to see
When you map in a file, its contents will consume address space of your
application. When the file is bigger than 3 GiB, since there is no more bits on
the address lines, you will not be able to map the file in completely all in
once.
On Sep 11, 2013, at 12:37, Alex Zavatone wrote:
>
> On Se
On Sep 11, 2013, at 12:03 AM, Maxthon Chan wrote:
> When you use the system call mmap(2) to map in a huge file you will find it
> useful.
>
How so?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or modera
On Sep 10, 2013, at 10:03 PM, Maxthon Chan wrote:
> When you use the system call mmap(2) to map in a huge file you will find it
> useful.
Especially if you want to map more than one, unmap one, mmap another, and so on
;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
When you use the system call mmap(2) to map in a huge file you will find it
useful.
Sent from my iPhone
> On 2013年9月11日, at 4:01, Abdul Sowayan wrote:
>
> Scott,
>
> I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and
> there is no virtual memory. Until you exceed th
On 10 Sep 2013, at 22:48, Scott Ribe wrote:
> On Sep 10, 2013, at 2:39 PM, Joseph Dixon wrote:
>
>> Some operations that would have taken 2 cycles may now be done in one.
>
> Some. Probably not many.
>
>> Surely that leads to a performance boost, right?
>
> Maybe, maybe not. The flip side i
On Sep 10, 2013, at 2:39 PM, Joseph Dixon wrote:
> Some operations that would have taken 2 cycles may now be done in one.
Some. Probably not many.
> Surely that leads to a performance boost, right?
Maybe, maybe not. The flip side is that pointers are twice as large, so half as
many fit in cac
On Tue, 10 Sep 2013 20:01:36 +, Abdul Sowayan said:
>I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig
>and there is no virtual memory. Until you exceed the 4 gig limit, I
>don't see why this matters.
One thing that pops to mind: it makes portability to/from OS X a litt
Scott,
I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and
there is no virtual memory. Until you exceed the 4 gig limit, I don't see why
this matters.
Abdul
Sent from my iPhone
On Sep 10, 2013, at 3:44 PM, "Scott Ribe"
mailto:scott_r...@elevated-dev.com>> wrote:
Wel
On 10 Sep 2013, at 23:30, Jean-Daniel Dupas wrote:
>
> For ARM, 64 bit matters because the instruction set has been updated to
> provider better performances.
>
> I just hope the performance boost provided by this architecture change will
> be enough to balance the slow-down due to the incre
Well, since nobody else has commented, let me be the first to say:
YES! YES! YES! THANK YOU APPLE!!
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
If we have hardware (registers) and software support for 64bit, doesn't
that mean the device can perform more calculations per CPU cycle? Some
operations that would have taken 2 cycles may now be done in one. Surely
that leads to a performance boost, right?
On Tue, Sep 10, 2013 at 3:01 PM, Abdul
For ARM, 64 bit matters because the instruction set has been updated to
provider better performances.
I just hope the performance boost provided by this architecture change will be
enough to balance the slow-down due to the increase of instruction and pointer
size.
Le 10 sept. 2013 à 22:01, A
Should be interesting to see how this plays out. When it comes to Java, when
you switch from a 32-bit JVM to a 64-bit JVM there is a 10% penalty doing so.
The main reason has to do with pointers. All pointers double in size. The
effect might be less in a Objective-C program.
Paul Franz
On Sep
On Sep 10, 2013, at 2:01 PM, Abdul Sowayan wrote:
> I'm curious, why does 64-bit matter? iPhone memory is still around 1 gig and
> there is no virtual memory. Until you exceed the 4 gig limit, I don't see why
> this matters.
Fragmentation of address space & dealing with large blocks... And it
34 matches
Mail list logo
