вы хотите сказать, что не поняли моей мысли, и мне надо было написать тут функцию, которая принимает integer, а в нее «приходит» string? по-моему довольно прозрачно
вдогонку могу сказать, что строгое типизирование со временем можно было бы применять во всех случаях, в том числе в вышеуказанном
на многих хостингах до сих пор php4 + php5 стоит, на больших так вообще консерваторы спасают пользователей как могут, хотя и соглашусь с вами, что многие счастливы, разработчики движков постарались и вовремя внесли необходимые изменения
p.s. только откомментил, уже в карму успели насрать :)
в первом случае количество неработающего кода окажется катастрофическим, во втором, если рассматривать его как начало реформирования всей парадигмы написания кода на пхп — вполне рационально, только я сильно сомневаюсь что начинание будет продолжено
представьте, что потоки в Ruby это рабочие, у рабочего есть пространство 1 квадратный метр, ему надо выкопать метровую яму, вы можете разместить на этом пространстве и 2 и 3 рабочих, но ЭФФЕКТИВНО эту работу будет выполнять только один
представьте, что потоки Ruby это кассир, как думаете, будет лучше, если она обслужит по одному покупателю, или будет пытаться обслужить всю толпу? ее внимание не сможет быть занято более чем 1 человеком в квант времени
так же и процессоры (ядра)
многоядерность — сравнительно недавнее изобретение, к которому еще далеко не все привыкли и научились работать, для него требуется новая архитектура (от операционных систем к приложениям), которая бы делала на 4 ядрах столько же работы, сколько могут делать 4 процессора, одинаковые по производительности, но увеличение количества пока что не повлияло на качество в той же мере
что касается других языков программирования, в Python'e, который я упоминал ситуация схожая с Ruby, Perl просто делает копию (клонирует) себя, так получается новый поток
и напоследок, я как-то заморачивался с написанием многопоточных приложений, пытаясь найти оптимальное количество тредов, приложение было подобным тому, что привел автор топика, но фишка в том, что вы запускаете несколько потоков, которые в свою очередь запускают несколько wget'ов, которые в свою очередь используют ваш интернет канал, ОСи и Ruby не сложно запустить несколько экземпляров одной программы, и тут треды — выигрыш, но bottle neck не процессор, а интернет-канал
если же вы в тредах пытаетесь рассчитывать числа Фибоначчи, то 1 тред будет кушать уже процессор, съедая его без остатка на расчеты (если ось не будет пытаться распараллеливать), не оставляя остальным ничего, либо ось будет таки распараллеливать ваши расчеты, но тогда каждый тред получит образно по 1 кванту времени и так будет по кругу, пока расчет не будет закончен
я вам и объясняю, вы видимо только на плюсы смотрите, а не на суть.
правило количество потоков (тредов) = количество ядер возникло потому, что на одном ядре нормально (без переключения контекста или блокировок) можно запустить 1 тред, который ГАРАНТИРОВАНО ПОЛУЧИТ нужное количество процессорного времени, а следующий тред, запущенный на этом ядре сможет работать только тогда, когда первый тред будет выполнен.
GIL все еще присутствует, а это означает, что ваши треды на одноядерной машине будут работать скорее всего через переключение контекста (т.е. сначала одна квант, грубо говоря, потом другая),
разница в 1.9.1 и 1.8 заключается в том, что треды стали нативными, это повлияло и на возможности, и на скорость, но никак не решило задачу параллельности
Current stable releases of Ruby use user space threads (also called «green threads»), which means that the Ruby interpreter takes care of everything to do with threads.… User space threads, on the other hand, can not make use of multiple cores or multiple CPUs (because the OS doesn't know about them and thus can't schedule them on these cores/CPUs).
здесь уже сама ось распараллелит задачи по ядрам или потокам, но Ruby сам этого не сможет сделать, это кстати цитата из ссылки, которую я дал, в противном случае (если у вас к примеру 2 ресурсоемкие задачи на одном ядре, то выполняться они будут точно НЕ параллельно, а либо с переключением контекста, либо друг за другом).
потоки в Ruby очень похожи на потоки Python, в них есть достаточно много ограничений, в общем смысле их стоит использовать по количеству либо ядер (либо ядер х 2, если smp), но никак не больше, к тому же в вашем примере (хоть это довольно незначительно) если соединение диал-ап, то потоки не выполнятся параллельно (это и не только, в зависимости от задачи, может стать bottle neck в приложении), к тому же присутствует GIL (Global Interpreter Lock), про ограничения можно неплохо почитать вот тут www.infoq.com/news/2007/05/ruby-threading-futures
пс. не принимайте как критику, это дополнение к изложенному :-)
mime тип application/x-mplayer-2
вдогонку могу сказать, что строгое типизирование со временем можно было бы применять во всех случаях, в том числе в вышеуказанном
p.s. только откомментил, уже в карму успели насрать :)
представьте, что потоки в Ruby это рабочие, у рабочего есть пространство 1 квадратный метр, ему надо выкопать метровую яму, вы можете разместить на этом пространстве и 2 и 3 рабочих, но ЭФФЕКТИВНО эту работу будет выполнять только один
представьте, что потоки Ruby это кассир, как думаете, будет лучше, если она обслужит по одному покупателю, или будет пытаться обслужить всю толпу? ее внимание не сможет быть занято более чем 1 человеком в квант времени
так же и процессоры (ядра)
многоядерность — сравнительно недавнее изобретение, к которому еще далеко не все привыкли и научились работать, для него требуется новая архитектура (от операционных систем к приложениям), которая бы делала на 4 ядрах столько же работы, сколько могут делать 4 процессора, одинаковые по производительности, но увеличение количества пока что не повлияло на качество в той же мере
что касается других языков программирования, в Python'e, который я упоминал ситуация схожая с Ruby, Perl просто делает копию (клонирует) себя, так получается новый поток
и напоследок, я как-то заморачивался с написанием многопоточных приложений, пытаясь найти оптимальное количество тредов, приложение было подобным тому, что привел автор топика, но фишка в том, что вы запускаете несколько потоков, которые в свою очередь запускают несколько wget'ов, которые в свою очередь используют ваш интернет канал, ОСи и Ruby не сложно запустить несколько экземпляров одной программы, и тут треды — выигрыш, но bottle neck не процессор, а интернет-канал
если же вы в тредах пытаетесь рассчитывать числа Фибоначчи, то 1 тред будет кушать уже процессор, съедая его без остатка на расчеты (если ось не будет пытаться распараллеливать), не оставляя остальным ничего, либо ось будет таки распараллеливать ваши расчеты, но тогда каждый тред получит образно по 1 кванту времени и так будет по кругу, пока расчет не будет закончен
правило количество потоков (тредов) = количество ядер возникло потому, что на одном ядре нормально (без переключения контекста или блокировок) можно запустить 1 тред, который ГАРАНТИРОВАНО ПОЛУЧИТ нужное количество процессорного времени, а следующий тред, запущенный на этом ядре сможет работать только тогда, когда первый тред будет выполнен.
я понятно объясняю?
насчет 1.9.1 прекрасно написано в комментариях вот тут, они не параллелятся
blog.reverberate.org/2009/01/31/ruby-191-released/
разница в 1.9.1 и 1.8 заключается в том, что треды стали нативными, это повлияло и на возможности, и на скорость, но никак не решило задачу параллельности
здесь уже сама ось распараллелит задачи по ядрам или потокам, но Ruby сам этого не сможет сделать, это кстати цитата из ссылки, которую я дал, в противном случае (если у вас к примеру 2 ресурсоемкие задачи на одном ядре, то выполняться они будут точно НЕ параллельно, а либо с переключением контекста, либо друг за другом).
пс. не принимайте как критику, это дополнение к изложенному :-)
у меня есть ответный патент, он заключается в том, что по фразе «заткнись у меня ferrari/bentley/lambo!» их система будет отключаться насовсем